Question for all. I have been hearing about TDD and unit testing a lot these days. Has the bug count reduced? I have to stream line the application I am working on. I am finding ways to do test automation. I am working on Selenium. But from the application design perspective I am also looking ways with TDD. So the question, do you see any change in the issue count, if you have worked with a team following TDD?
My first thought is to wonder what we're comparing the issue count to? Presumably this is the first time we've written the software that's being tested, so it's difficult to know for sure whether a practice that includes TDD has certainly resulted in fewer issues.
TDD is a practice that mandates developers writing tests before they write code. It is a fundamental mindset shift in the way someone goes about their development. I don't believe testers can practice TDD unless they are writing the actual application code.
TDD and unit testing are not the same thing. Unit tests are a result of TDD, but the practice of TDD is not the only way to get unit tests. Unit tests can be written after the code too.
As testers, we should know, to a certain extent, what unit testing is in place, and what coverage these tests provide. And, generally, a good base of unit tests will give us a better starting point. The issues found in testing are fewer, because the developers have thought more about the code themselves. Generally.
I am implementing the best I can do regards to design and testing. Testing is worthless, if design is not correct. So design is what I am looking at.
I'm not quite sure why TDD is being cited as a design practice, unless specifically speaking to the design of code? If you want to look at "are we building it right?" then TDD is the practice for you. If you want to look at "are we building the right thing?" then it is not (verification and validation).
I have reservations with #TDD. Implementing TDD, the project deadlines also needs to be stretched. Right?
I think this depends on what your current development practices are. If unit tests are already in place, but they're being written after the code rather than before it, then implementing this practice shouldn't stretch out deadlines. If there's no unit testing, then development may start to take longer, but in theory at least you should see some corresponding benefits in testing as the code is delivered in a much better state.
Finally, if you're really curious about TDD, the Wikipedia page looks pretty comprehensive.
Experts of TDD, please voice any disagreement below...
Thanks for answering my twitter queries.
ReplyDeleteI never said that TDD is testers cup of tea. All I was asking Jyothi ( @aarjay) was whether TDD really helped the bug count to go lower. You very well answer this quetion of mine as well.
Thanks
In my experience, TDD is faster than writing tests after the code.
ReplyDeleteFirstly because, when writing the tests first, modern IDEs will generate stubs for the classes and methods that you define in your test.
But also because, when writing tests after, I tend to need to rewrite the code to make it testable. Writing the tests first results in testable code that is easier to refactor into shape.