Announcement Announcement Module
Collapse
No announcement yet.
How to implement TDD using JUnit with Spring/ Hibernate? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to implement TDD using JUnit with Spring/ Hibernate?

    Hello,

    I hope I'm posting in the correct forum. I'll start a project using Spring + Hibernate + JSF and would like to know what should be the best practice to apply the approach of TDD (Test Driven Development) using those technologies. Is there any step-by-step on it? Appreciate any reply.

    Thanks. Regards.
    Last edited by DistillingSpring; Nov 16th, 2006, 09:51 AM.

  • #2
    I'm using the Test chapter of the Spring Reference documentation as suggested in this thread:
    http://forum.springframework.org/sho...ighlight=junit

    Any other suggestion is welcome. Thanks.

    Comment


    • #3
      I just finished with the Test chapter and I have to say that I still need a more specific step-by-step usage of this approach, since I'm thinking to advice the team to goes in this way (or not!). Regards.

      Comment


      • #4
        Have you read some general resources on TDD (e.g. follow the links in the Testing chapter you just finished)? Once you are used to TDD in general, there is nothing specific to the technologies you mention, other than what you can pick up from their respective reference material. Most of the time your code should not expose details of the underlying technologies, so unit testing is pretty generic (or would be ideally).

        A big barrier to unit testing of web applications is the view rendering technology. Everyone wants to use JSP, and that makes it practically impossible to test the views. If you are tied to JSF you could take a look at Facelets, which at least opend up the possibility of testing the views (I remain unconvinced of the ultimate practicality). These considerations have nothing to do with Spring (or Hibernate).

        Comment


        • #5
          One approach for unit testing DAO classes is to use dbunit and a file based SQL database like hsql. You can create a database schema in hsql that matches your real schema. Then you create unit test classes using dbunit. Dbunit does a couple of things, it can set a database to a defined base state from a XML file and it can check a database table to see if it matches a predefined data set. Dbunit test classes usually follow this pattern, set a table to a defined state, run a DAO operation to change the table, check the table after the fact to see if the has the expected results. I have used this for JDBC based DAO classes but it should work the same for hibernate based DAOs.

          Comment


          • #6
            I agree with the last two posts. There is lots of information about this just search for it.

            The biggest problem I've seen is a cultural one, solve that and your nearly home and dry.

            Using something like HSQL helped massively, the tests just fly by. Coupled with that MockObjects in general and for those hard to reach places. As david said views are a pain. We used StrutsTestCase (HttpUnit useful as well) which allowed us to test we were being sent to the right place and the action gave us the right data. Beyond that we found the effort of automated testing for the UI was actually counter productive.

            Comment


            • #7
              Thank you very much. For this reason I believe forum is a very powerful tool. Of course everyone knows what googling is nowadays, but find out information that is difficult to test in views and also what is the practice for all this stuff, is not that easy to see. Thanks for the insight. One question remain unsolved for me. Do you really get this "test first" approach in practice or you find out more useful build the code and make the test later? I know that it's what unit tests are all about, but it's always hard to move from an idea to other, mainly when one is responsable for the architecture. Regards.
              Last edited by DistillingSpring; Nov 16th, 2006, 11:57 PM.

              Comment


              • #8
                Generalisation maybe, but I think if your attitude is I'll write the tests later, you won't write any tests. I've seen this in practise where everytime the team were going to write some tests something else more business led came along. We got to the point where 3 years down the line the application had no unit tests. The managers didn't get TDD so it wasn't deemed important.

                It was a monster of a problem and yours truely sat down to write tests weeks at a time. If people hate writing tests anyway, they really hate writing tests for weeks at a time. After refactoring the application, with tests to back it up we ended up with 80%+ coverage which I was quite pleased with.

                I'm not sure that sitting down and writing all your tests and then your code is the approach I would like to take. I usual write some functionality and write a test..... repeat until finished. I don't write 4 hours of code, its typically minutes. I find doing it like this, makes me write code that is easy to test. If its not I find out about it straight away and refactor.

                Purists may disagree, but I've found it the best way to work. BTW, I never write code without tests now it just doesn't work (IMHO).
                Last edited by karldmoore; Nov 17th, 2006, 03:00 AM.

                Comment


                • #9
                  I usual write some functionality and write a test..... repeat until finished. I don't write 4 hours of code, its typically minutes. I find doing it like this, makes me write code that is easy to test. If its not I find out about it straight away and refactor.
                  Very good hybrid approach for unit tests working in practice (IMHO as well). Thank you. Regards.

                  Comment


                  • #10
                    Couple of things I would add.

                    1. If the unit tests start failing, assume your code broke something rather than the unit tests. I've seen sooo many developers commenting tests out because they must be the problem. No, no, no.

                    2. If bugs are found, write a test first to prove the existance of the bug. The test will initially fail as there is a bug. Fix it and re-run the test, it will now pass. I've seen the same bugs occuring again and again, and being allegedly fixed again and again. Its not fun and its so easy to prevent.

                    TDD is difficult to get people into, but once you get it I doubt you'll revert to old ways.

                    Comment


                    • #11
                      It's the kind of answer that I and a lot of people (I guess) -- need to know. Very dirty hands working on TDD. Thank you very much again. I will continue with my researches and practices at the same time and as soon as I have some of my own humble considerations, I'll post here. Regards.

                      Comment


                      • #12
                        Originally posted by DistillingSpring View Post
                        It's the kind of answer that I and a lot of people (I guess) -- need to know. Very dirty hands working on TDD. Thank you very much again. I will continue with my researches and practices at the same time and as soon as I have some of my own humble considerations, I'll post here. Regards.
                        As I said I can only speak from my own humble experiences. Look forward to hearing what you find out.

                        Comment

                        Working...
                        X