#37-Do I Really Have to Test Everything? First Answer

This is my first answer to the question posed last week.  There will be two more in future weeks.

Transcript

"Do I Really Have to Test Everything?" First Answer

As I mentioned last week, this is a quite frequent question in my TDD/ATDD 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. 

Answer #1: It's not the right question. 

The truth is, everything will be tested. The real question is: by whom?

• It could be you or your team, as you are developing the feature.  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 a 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.  This is true unless you created something that nobody ever uses, which is something we never want to do, obviously.

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 created the feature 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 of 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 a product that was not working properly. 

At long last once the defect is uncovered, it can damage the reputation of the team that created it.  That could be your team. 

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 products that are buggy.  Your reputation is suffering, and you don't even know it, or that you should 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 undo your work and try again. That might be most efficient course of action depending on the nature of the work.  In any case nobody know will know you made that mistake but you, you save yourself the embarrassment and potential harm to your career while also safeguarding the reputation of your organization and its 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.  Those 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 up front. 

But there's more...