A Downside to TDD
You may have noticed that I tend to shift subjects quite a bit. I talked about Agile a while ago, and have moved away from talking about it. I needed to grow and learn about the processes, which I have done a little. I'll always be a student in this subject, never fully grasping all that it has to offer. Even so, I love the whole Agile movement. What attracts me most is that this methodology embraces ideas like putting people first, development in smaller iterations, cycles, and chunks instead of developing sofware in a waterfall approach (which leads to problems in its own).
One of the emphasis of TDD is development in small chunks, and create automated unit tests first. Automated unit tests handle several development tasks:
- It forces you to see how your components are consumed by the client early on; the emphasis tends to be design the architecture on paper and up front. When this is the emphasis, the design sees problems down the road because the consumer requires different input or business rules than what was thought of during the requirements gathering.
- It serves as a unit test, and will never lose that status; it continually tests the code even after the code is released, maintained, and enhanced in future releases.
While this is all good and handy, refactoring poses some challenges. TDD doesn't iron out all the kinks at the beginning like it should, at least for the average Agile developer. While people like Kent Beck or Martin Fowler may never run into this issue, I run into it in my code. This is because even though I'm developing tests, there are some minor unforseen challenges that come down the road.
In a sense, this is what TDD and Agile is all about: developing in small manageable chunks and only focusing on the current task, not looking ahead. So when a future piece of the application comes into play that requires changes to older code, refactoring needs applied. But refactoring doesn't get applied to only the targeted class; rather, it targets any and all unit tests that have been coded for it. Depending on the size of the code, this could be a lot of tests to change. To find out, make the change, and compile the project in Visual Studio, Eclipse, MonoDevelop, or whatever software product you use. I know most TDD'ers consider this not a proper TDD approach (to rely on the compiler), but the compiler easily points out where changes have to be applied in unit and integration tests (integration tests are also a factor too in all of this).
I'm not against TDD or unit/integration tests; I love them, but when you design these tests, think from a object-oriented perspective in these tests as well and plan ahead, so that you can try to reduce the amount of changes you need to make when you refactor code. Your code not only needs a good design, but your unit/integration tests need a good design too.