Problems with Test-Driven Development
At work we are slowly discovering some of the problems with trying to do Test-Driven Development (TDD). On the surface, it seems like such an easy thing to do. Before you write any code, your create the unit tests to exercise the code. This not only gives you an excellent regression test suite, but it also forces you to think about the overall design and the inputs and outputs required by each method and class. By following this technique I know that my own designs and coding has improved. However, with all of that said, there are still problems:
- How to properly teach TDD newbies how to properly go about creating their tests? For too many people on our team, they view tests as simply a way to exercise the code and do not see them as an exercise in design.
- How do you do TDD with J2EE? I am sure that there are many ways of properly hooking JUnit tests up to work with deployed, managed code, but when you first start doing TDD, this can be a huge hurdle to overcome.
- If developers do not understand Object-Oriented design and programming, how do you get them to implement proper unit tests? Or, if developers do not understand how to do design how are they suppose to work TDD into that design process?
Unfortunately I do not have any answers to the above questions. There are simply things that I have observed over the past month of trying to do TDD with a team of about 20 developers.