#36-Do I Really Have to Test Everything? Introduction

Teaching Test-Driven Development, either in the unit testing form for developers or the acceptance testing that anyone can learn and do, this questions almost always arises at some point.  It's actually an excellent question and can yield a lot of value in answering it.  This episode will explain why.

Transcript

"Do I Really Have to Test Everything?", Introduction

I find training to be an amazingly satisfying experience. It is an opportunity to contribute to other people and enhance their capabilities, but also most teachers will tell you that you never really know anything as well as you do when you've had to explain it to someone else.

In other words, the teacher learns from a teaching experience every bit as much as the students do. One way this occurs is when students ask good questions. All questions are helpful because they represent an opportunity to enhance the knowledge of the questioner, but the best questions, the ones I always look forward to the most, are the ones that I do not immediately know the answer to. Those questions represent an opportunity for me to explore my knowledge and in so doing, enhance it.

When I train people to do test-driven development, there is a question that comes up routinely.  It arises because I always do the training hands-on, either by teaching them how to write acceptance tests (which everyone can do), or unit tests (which developers and testers can do).  Either way, the question is:

Do I have to test this?

This question usually arises regarding some very simple aspect of the system. For example, sometimes adding a feature involves creating an entity for the sole purpose of storing the details about something. This could be a record in a database, or an object in memory, or something similar. For example, they might create an ability for the system to store all the details about a customer. Those details might include their name, their address, perhaps an email or other identifier, a user ID, and so forth.

The student will ask "should I write a test that creates an entry, populates it with details, and then verify that each detail is correct by retrieving it?”  Their point seems to be that such a test feels trivial and unnecessary and would really have no purpose because such a simple thing is highly unlikely to develop a defect in the future.  In fact, some books on unit testing specifically warn against "testing getters and setters", which is the same point stated in more technical language.

When I tell them that yes, that part of the system needs a test to drive it too, I can tell that this is a bit frustrating to them. Inevitably they will throw up their hands and say something like:

"Do I really have to test everything?"  

If the person is a tester, especially, I can see the skepticism in their eyes.

I think being skeptical is good.  It enhances your critical thinking and allows you to make contributions if it is good-natured and reasonable.  It also leads to good questions.

This is the kind of question I was referring to above. It is a question that I do not want to give short shrift to, because the answer as to why such a test should be written provides a rich opportunity to investigate test-driven development itself and discover much about what makes it work.  In fact, my answer is so rich that it will take three separate postings to fully express it.

I have written about this before, so it's possible some of you may be familiar with where I am going here.  If so, then this might represent a bit of repetition for you, although that can be a good thing anyway.  But I suspect most of you do not know what I'm about to communicate and so this will be a real opportunity for you to learn, as it was for me to work it out in the first place.

Stay tuned for part one of my answer next week!