Why Write Tests? 5 Reasons Why I Write Tests

In this lesson

There are many, many reasons we write tests. These are some of the most important reasons I do. Watch and see if you agree.


Tap on time to skip ahead


In this lesson, I’m going to talk about some reasons why I write tests. Hopefully these reasons will overlap with the reasons you write tests. Or will give you some ideas that will benefit you to cause you to start writing tests.


Reason #1: Here I have some code that I’ve written. It’s a library that interacts with a SQLite database. It’s obvious that when I’m writing this I may not have any code yet that uses it and I want to start exercising it as early in the dev cycle as possible. As soon as I start writing functions like open or close, I can immediately write tests against those functions, even without a database. I don’t have to have any tables yet, all I have to do is create a simple database. Here I can write some tests that exercise immediately, early in the dev cycle, some of my code that I just wrote.


Reason #2: To be able to test my code before anything else has been written that uses it. Obviously, this is a framework. I may not have even written the UI yet that uses this framework. How do I test it? Or how do I verify that it is even going to work before I even write the UI? I can write tests without a UI that will exercise all facets of my code. You can see I have a lot of different tests here. This allows me to verify that it’s going to work and have a reasonable certainty that when I do use it in a UI or somewhere else that it’s actually going to function.


Reason #3: To help me develop my APIs. Let’s look at an example here. In this framework, I have three different overloaded versions of the same function called executeUpdate. This one takes no extra arguments other than the SQL string, this one takes an array of parameters and this one takes a map of parameters. You’ll notice the underlying call I’m making to the third party library that I’m fronting, uses in this instance, withArgumentsInArray. The same here. But in this one an argument called withParameterDictionary. What I decided, because of the fact that I was writing tests against this, was that I wanted to be able to make a consistent API across all of those calls. So I chose parameters instead.


Reason #4: It serves as a form of documentation. If I want to look at my tests, I can see, well this is simple. How do I call open? But you’ll notice that I have a try in front of that because it declares that it throws. But I can look at my entire API against the code that I wrote in the framework and I have tests that exercise that API and I can see how I wrote code against it. When I’m ready to write real code instead of tests, I can use the tests as a form of documentation to see how I did something.


Reason #5: As protection against future changes by me or someone else. Let’s say somebody comes along after my code’s been in place for several months and looks at this line right here and says, “There’s too many parentheses here, we don’t need this.” And thinks this is an actual mistake and takes this out. The code still builds but when the tests are run, the code compiles fine, the IDE is compiling and it will run my tests, but thankfully I have tests in place that are going to check this. This will be caught as a failure because those parentheses are in fact important. Because of the tests here, I was able to catch an inadvertent change by another developer who thought he or she was making an improvement to the code but in fact deleted code that was required.