Some cases for TDD
Introduction
I will argue that software development consists of the following steps:
- Figuring out requirements
- Implementing functionality meeting the requirements
- Fixing broken functionality
- Test the newly implemented functionality
These steps doesn’t necessarily come in chronological order. Indeed, some of the steps are made simultaneously.
Figuring out requirements
Obviously, one needs to figure out what needs to be done. Requirements comes out of some business or technical need. These requirements can be written down in a document, or they can basically be some sort of verbal agreement between the developer and the business owner (which can also be the same person, which makes communication vastly easier).
Implementing new functionality meeting the requirements
Once requirements have been figured out, one can proceed to implement functionality which meets these requirements.
This is what most developers consider the fun part of software development.
However, the fun part of development can easily come to a halt once you reach the next part of the development:
Fixing broken functionality
While implementing functionality, it is almost impossible to get everything right in the first go. Actually, getting things right in the first go will make most senior developers uneasy. “I got it right in the first try… Something must be wrong!”.
The more code you write, the more difficult the debugging task become. The quick pace of development quickly grinds to a halt. This part of development is not the “fun” part.
Last, but not least, the last part of software development. Testing.
Test the newly implemented functionality
Now, some of you might not think that you are doing testing of the software that you develop. The software just does what it is supposed to when you run it, right. Well. That is a form of testing. Manual testing with yourself as the tester. I sincerely hope that none of you deliver software without having done any tests. Essentially, this would mean that you have actually followed through with the joke saying: “it compiles - ship it”.
So, I think that we can establish that testing is a necessary step of software development.
Is fixing broken functionality really a necessary step?
I would argue, that it is not. You can still deliver high-quality software without having to go through lengthy debugging sessions, and long nights fixing broken functionality.
Now, saying that you never need to fix broken functionality is maybe a bit of a stretch. I will still argue that one can certainly limit the amount of time spent in this phase by moving testing earlier in the development workflow.
TDD
By employing TDD in your workflow, you will never add much functionality in any step, and the functionality you have already added will be covered by automated tests. Therefore, is is most likely the code you have just added that has broken the functionality.
Actually, breaking functionality is an integrated part of TDD development cycle. But the whole idea of TDD is that you will not have broken functionality for long enough for this to become as issue.
Validating requirements
One thing we haven’t touched upon, is how TDD can help us in another step of the process. Figuring out requirements.
By moving the the test part early in the process, one needs to validate the requirements before starting coding. If the requirements are vague or incomplete, you will not be able to write tests for them. If a requirement is hard to write a test for, maybe the requirement has an issue. This is quite likely, as requirements is still one of the hardest thing to get right in software.
Testing can actually be moved so early in the development process, that they go before requirements. By thinking about how one can test a requirement, instead of just writing a requirement, you make sure that the requirement is clear and unambiguous.
Closing remarks
I hope this article has helped in making you realising, that pushing testing to the earliest phase of the development effort can avoid many of the problems that take the fun out of software development. After all, one of the most enjoyable parts of software development is delivering cool functionality to users quickly.