Gaining Code Confidence Through Testing
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
One of the most interesting paradoxes of programming is this: As you gain experience, the confidence you have in your code tends to decrease. This is not because a programmer's talent decreases over time. No, it is because the longer you program, the greater the quantity and variety of bugs you have seen. With more experience, programmers realize that in systems as complex as software applications, bugs are inevitable. While newer programmers are certain that their code is flawless, experienced programmers know there are flaws, and only worry how many.
The situation may seem dire, but we are not without hope. We have ways to mitigate, minimize, and even prevent bugs. Among these techniques are documentation, proper software design, and software testing. While all of these options are important, I think the most neglected among new programmers is software testing. This article will discuss how a programmer can increase code confidence through software testing.
What Is Software Testing?
For the first few years of my life as a programmer, testing was nearly indistinguishable from debugging. I tested my programs as I was building them, running them in the same way that the programs' end users were supposed to do. I tested only the feature I was building at the moment, and if something was broken I would debug and fix it. This type of software testing is called manual testing, and its value should not be underestimated. However, manual testing has a few very large holes:
- Manual testing is slow. You can only test as fast as you can use your program.
- Manual testing is limited. You generally test only the feature on which you are currently working—other parts of the system may break due to your changes, and those bugs will be missed.
- Manual testing relies on your (fallible) memory. Even if you try to test your entire program after each change, you will almost certainly forget to test certain aspects of it.
Manual testing is great, but to really gain confidence in your code, you need automated testing. An automated test is a piece of software specifically designed to test your software. Generally speaking, there are two kinds of automated tests:
- Unit tests are used to test how a single unit of your program works.
- Integration tests are used to test how the entire program works with other systems.
In practice, a lot of automated tests lie somewhere in the spectrum between unit tests and integration tests.
All of these types of tests are important, but we will focus on unit tests in this article, because unit tests are the most fundamental automated tests. Automated tests offer some major advantages over manual testing:
- Rapid. Automated tests are fast because the computer executes them.
- Comprehensive. You can easily run automated tests for your entire program when you make a change, instead of just the part of the program on which you are currently working.
- Repeatable. Once you have written a suite of automated tests, they will all be executed every time you want to run your tests. You don't have to worry about forgetting any of the tests.
Why You Need to Test
As I mentioned earlier, I spent my first few years programming without writing any automated tests. I didn't write automated tests because I realize they even existed, and I didn't really understand what use they would have. On smaller, short-term projects, the lack of tests seemed fine; I didn't even recognize the need for tests. But as the size and complexity of my software projects grew, I started to feel the pain.
On one occasion, I was releasing a new version of a Chrome extension with some great new features. Only after I had released the new version did I realize that the new features broke some of the extension's most vital functionality. I quickly fixed the bugs and released another version, only to find I had broken something else. I think I released four versions within an hour before I got the extension working correctly again. By the end of that hour, I had almost no confidence in my code. The lesson I eventually learned from experiences like this is that you should write unit tests, because they will give you the confidence to build new features, fix bugs, and release new versions of your software. Write and execute thorough tests, and you can ship with confidence.
How to Test
I think the hardest part of unit testing is figuring out how to write tests. Having never seen a unit test, I struggled to imagine what a unit test would look like. We'll walk through an example here that will show how to write tests for a simple JavaScript function, and how to use those tests to have confidence in our code as we refactor the function. We will create a remainder function, which will accept two numbers, x and y, and return the remainder of x divided by y. The first version of the remainder code is intentionally ridiculous to give us room for a refactor later:
function remainder(x, y) {
var decimalMatch = /\d*(\.\d*)/;
var decimal = parseFloat(decimalMatch.exec((x/y).toString())[1]);
return Math.floor(decimal * x);
}
You cannot reasonably expect to test every possible input combination, even for a trivial example like this one. Instead, you should test the places where things are different–the edges. In this case, I would want a test in these situations:
- When x and y are the same
- When x is 0 and y is not 0
- When y is 0 and x is not 0
- When x or y is really large and the other isn't
- When both x and y are really large
- When either x or y is negative
- When both x and y are negative
And so on. Though I have listed quite a lot of possible tests, it's not an infinite number of tests. Let's take a look at how we might write one of these tests.
// A helper function for testing the remainder function
function testRemainder(x, y, expected, description) {
var result = remainder(x, y);
if (remainder === expected) {
console.log('pass: ' + description + '\n');
} else {
console.error('FAIL: ' + description);
console.log('Expected the remainder of ' + x + ' divided by ' + y +
' to be ' + expected + ', but the result was ' + result);
}
}
// An actual test
testRemainder(13377331, 42, 37, 'A large x and small y');
Once you have written all of the tests, you can refactor the remainder function so that it is not so ridiculous:
function remainder(x, y) {
return x % y;
}
After the refactor, run all your tests again. If all the tests pass, you can have confidence in your refactored code.
What to Test
You don't necessarily need to test every single aspect of your program. Testing libraries can give you a "code coverage" report, which will tell you what percentage of total lines of code have been executed with your tests. That number is useful, but even more useful is seeing exactly which lines of code have not been executed with tests. Some code does not need to be tested. Some code should not be tested. Also, just because a line of code was executed with a test does not mean that it has been properly "tested." It just means that the line of code was executed while a test was running; if the test isn't well written, the line of code may not have really been "tested."
Your tests should serve as a description of what your code is supposed to do. If any parts of your code are not actually part of the main purpose of your code, those parts don't really need to be tested. For instance, I recently had to add a special check in some of my code to find out whether a feature from another part of the system was in place. It looked something like this:
var items;
if (newFeature.isReady) {
items = ['a', 'b', 'c', 'd'];
} else {
items = ['a', 'b'];
}
buildUI(items);
The new feature was expected to be fully available within two weeks, at which point I would remove the feature check. Writing a unit test for that code would have been counterproductive because the test would not describe what the code was supposed to do, because the code was going to build the UI with some items in either case. The question was which items did not affect the functionality of the code, and therefore should not be included in the tests.
When to Test
There is a lot of discussion and debate today about when is the best time to write unit tests. Advocates of test-driven development say that you should write your tests before you write your code. Other people argue that writing tests before writing code is impractical at best and harmful to the user experience at worst, because too much focus is given to the tests instead of the application itself. In my experience, writing tests before writing code is beneficial because it can help you think through your software's design. However, I have also found that it can lead to too much time spent thinking and not enough time actually writing code. My suggestion is to write your tests sometime before you release your software, but the specific timing doesn't really matter.
Who Should Test
Different organizations handle the responsibility of software testing in different ways. In general, if you are writing code, you should at least be writing unit tests for that code. Writing good tests is one of the marks of a high-quality, mature, confident software developer.
I hope this article has given you insight into how software testing works and why investing in it is worth your time. Now go write some code—and tests!