This is a quite frequent question in my Test-Driven development classes. I really like it because it presents a wonderful opportunity to make some significant observations about TDD and testing in general.
I have three answers to this question, so this posting will be in three parts. One today, one tomorrow, one the day after that.
It's not the right question. The truth is, everything will be tested, the real question is: by whom?
- It could be you, as you are developing the software. That's the standard practice of TDD: the test is written as part of the development process in the first place.
- It could be someone else within your organization. Perhaps another developer is tasked to test what you created, or perhaps you have a separate testing team, QA, QC, SAT testing, something along those lines.
- If it's neither of these, then it is your customer, when using the product. They will test it by using it.
If it's a separate testing effort within your organization, the problem is that there may be a significant delay before you get the results. Testing is scheduled and often lags significantly behind development. When a report of a defect arrives, it may be days, weeks, or even longer since you wrote the code and handed it over. It will no longer be fresh in your mind and so you'll have to spend time tracking down the cause of the problem before you can fix it. This, of course, creates cost in terms the hours you spend and the delay this causes.
If it's your customer, the costs go up. First, this can damage the reputation of your product; it is seen as faulty to some degree. It can also damage the reputation of your organization overall because you released software that was not working properly. At long last once the defect is uncovered, it can damage the reputation of the developer who created it. That could be you.
What may be even worse than this is that a customer, having encountered a defect, may not tell you at all. They feel no responsibility to do so. They may simply be living with it, annoyed with you and your product, and may well tell colleagues of theirs that you put out software that's buggy. Your reputation is suffering and you don't even know it, or to repair it.
If it's you, and you introduce a defect, you find out immediately. If you are doing TDD properly your tests are fast and so you run them frequently. If one goes red, you know it must be something you just did, as they were all green minutes ago. Finding it is trivial, and maybe you won't even bother looking. Just Ctrl-Z and try again, that might be most efficient depending on the nature of the work. In any case, nobody knows you made that mistake but you, you save yourself the embarrassment and potential harm to your career while also safeguarding the reputation of your organizations and it's products.
Do you need to test everything? The truth is you want to test everything, not to satisfy some process requirement but because it is in your own best interest to do so. Developers who get comfortable working this way routinely exclaim that they wish they'd always been doing it, that they never want to go back to working without writing tests.
I have much more to say. Stay tuned for answers 2 and 3.