Unit Tests
Unit tests are exactly what they sound like. They are small, self-contained segments of code that test very small, targeted units of functionality. Rather than check to see if the whole application works, we can break the functionality into pieces to pinpoint exactly where errors and bugs are occurring.
Unit tests are designed to either pass or fail. Is this feature working the way you want it to, yes or no?
The Parable of the Dinosaur
Here is an example of unit testing gone bad.
In Jurassic Park (the book, not the movie), Dr. Grant asks the scientists how they can be sure that the dinosaurs are not breeding.
The scientists assure Dr. Grant that every precaution has been taken. They engineered the dinosaurs to all be female. They had the island blanketed with motion detectors to count each and every dinosaur every five minutes. They created a computer algorithm to check the number and types of dinosaurs found by the motion sensors and the number only changed when a dinosaur died. There had been no escapes. They knew everything happening on the island, and they were completely in control.
Dr. Grant asks them to change the parameters of the computer program to look for more dinosaurs than they were expecting to have. The scientists humor Dr. Grant and change the algorithm to search for more dinosaurs. Lo and behold! There are more dinosaurs. After running the program several more times with increasing numbers they eventually discover there are over 50 extra dinosaurs on the island. Oops!
The program had been set up with the expectation that the number of dinosaurs could only go down, never up. Once the program reached the number of dinosaurs it was expecting to find, it stopped counting, and the scientists never knew there was an issue. The program anticipated the outcome of dinosaurs dying or escaping the island but never the possibility that life could find a way.
Reasons We Unit Test
Bugs, like life, do find a way. The first thing to remember in computer programming is that the computer is stupid. The computer only does what you tell it to do. It can’t infer what you meant. It is important to verify that you are giving the right directions to the computer and the best way to do that is to test your apps.
One major reason to unit test an application is to eliminate crashes. The single biggest reason that most app submissions are rejected by Apple is because they crash. Even if Apple doesn’t catch your crash, users have a talent for finding the one combination of things that will cause your app to crash. These are the users who tend to leave one-star reviews on the store, which is something we want to avoid if at all possible.
Unit tests also expose logic errors in our code. In the Jurassic Park example, the code being run had a logic error that prevented the scientists from discovering the problem until it was too late. We don’t want that to happen to you.
Writing tests also helps you write your code. Have you ever started writing a piece of code only to figure out that one feature you spent days working on wasn’t really going to work out in your project? By thinking critically about what specifically you want your application to do, you can avoid writing overly complicated and unnecessary code. They can inform the design of our code: what part of the code has what responsibilities, and how we recover if something unexpected happens.
Designing Good Unit Tests
As we will soon discover, writing a unit test is not difficult. Writing a good unit test is another story altogether.
There are generally three types of unit tests:
-
Debugging: These tests are built around bugs to ensure that when you change the code these bugs do not reappear. Sometimes when we are coding we make changes to the code that affect bugs that we have already resolved. Since we do not want to see that bug again, we need to write tests to make sure that the bug has not reappeared when we change anything.
-
Assert Success: We are testing to make sure you are getting a result you want.
-
Assert Failed: We are testing to make sure you are not getting a result you don’t want.
We might wonder why you would need a test to assert failure. Isn’t the point of testing to make sure that features we created work properly?
Think back to the Jurassic Park example. The scientists created tests to make sure they were finding all of the dinosaurs they were looking for. They asserted success once the number of dinosaurs they were looking for was reached.
Sometimes it is as important to write a test that we expect to fail to make sure that we are not getting a result we don’t want. Had the scientists also included a failure assertion test, they would have discovered that they were getting results that made no sense: there are more dinosaurs in the park than there are supposed to be.
