14.3. Unit Testing in Action¶

14.3.1. What to Test¶

When writing tests for your code, what should you test? You can't test every possible situation or input. But you also don't want to leave out important cases. A function or program that isn't well-tested might have bugs lurking beneath the surface.

Regardless of the situation, there are three types of test cases that you should consider: positive, negative, and edge cases.

1. A positive test verifies expected behavior with valid data.
2. A negative test verifies expected behavior with invalid data.
3. An edge case is a subset of positive tests, which checks the extreme edges of valid values.

Considering positive, negative, and edge tests will go a long way toward helping you create well-tested code.

Let's see these in action, by writing tests for our isPalindrome function.

14.3.2. Setting Up¶

Here's the function we want to test:

1function reverse(str) {
2   return str.split('').reverse().join('');
3}
4
5function isPalindrome(str) {
6   return reverse(str) === str;
7}

repl.it

Code along with us by forking our repl.it starter code project, which includes the above code in palindrome.js and the Jasmine test runner code in index.js. Note that we have removed the console.log statements from the original code and exported the isPalindrome function:

module.exports = isPalindrome;

You have become used to testing your code by running it and printing output with console.log. When writing unit-tested code, we no longer need to take this approach.

Finally, create spec/ folder and add a spec file, palindrome.spec.js. This file should include imports and a describe block:

1const isPalindrome = require('../palindrome.js');
2
3describe("isPalindrome", function(){
4
5   // TODO - write some tests!
6
7});

Okay, let's write some tests!

14.3.3. Positive and Negative Test Cases¶

 1const isPalindrome = require('../palindrome.js');
 2
 3describe("isPalindrome", function(){
 4
 5   it("should return true for a single letter", function(){
 6      expect(isPalindrome("a")).toBeTrue();
 7   });
 8
 9   it("should return true for a single letter repeated", function(){
10      expect(isPalindrome("aaa")).toBeTrue();
11   });
12
13   it("should return true for a simple palindrome", function(){
14      expect(isPalindrome("aba")).toBeTrue();
15   });
16
17   it("should return true for a longer palindrome", function(){
18      expect(isPalindrome("racecar")).toBeTrue();
19   });
20
21});

 1it("should return false for a longer non-palindrome", function(){
 2   expect(isPalindrome("launchcode")).toBeFalse();
 3});
 4
 5it("should return false for a simple non-palindrome", function(){
 6   expect(isPalindrome("ab")).toBeFalse();
 7});
 8
 9it("should be case-sensitive", function(){
10   expect(isPalindrome("abA")).toBeFalse();
11});
12
13it("should consider whitespace", function(){
14   expect(isPalindrome("so many dynamos")).toBeFalse();
15});

14.3.4. Edge Cases¶

Recall our definition of edge case:

An edge case is a test case that provides input at the extreme edge of what the unit should be able to handle.

Edge cases can look very different for different units of code. Most of the examples we provided above dealt with numerical edge cases. However, edge cases can also be non-numeric.

In the case of isPalindrome, the most obvious edge case would be that of the empty string, "". This is the smallest possible string that we can use when calling isPalindrome. Not only is it the smallest, but it is essentially different from the next longest string, "a"---one has characters and one doesn't.

Should the empty string be considered a palindrome? That decision is up to us, the programmer, and there is no right or wrong answer. In our case, we decided to take a very literal definition of the term "palindrome" by considering case and whitespace. In other words, our definition says that a string is a palindrome exactly when it equals its reverse. Since the reverse of "" is also "", it makes sense to consider the empty string a palindrome.

Let's add this test case to our spec:

it("should consider the empty string a palindrome", function(){
   expect(isPalindrome("")).toBeTrue();
});

Now run the tests, which should all pass.

You might think that another edge case is that of the longest possible palindrome. Such a palindrome would be as long as the longest possible string in JavaScript. This case is not worth considering for a couple of reasons:

• The length of the longest string can vary across different JavaScript implementations.
• The most recent JavaScript specification, ES2016, states that the maximum allowed length of a string should be 2 ⁵³ - 1 characters. This is a LOT of characters, and it is unrealistic to expect that our function will ever be given such a string.

14.3.5. Toward a Better Testing Workflow¶

In this case, we had a well-written function to write tests for, so it was straightforward to create tests that pass. Most situations will not be this simple. Your tests will often uncover bugs, forcing you to go back and update your code. That's okay! This is precisely what tests are for.

The workflow for this situation is:

1. Write code
2. Write tests
3. Fix any bugs found while testing

The rest of the chapter focuses on a programming technique that allows you to completely eliminate the third step, by reversing the order of the first two:

1. Write tests
2. Write code

As you will soon learn, writing your tests before the code is a great way to enhance your programming efficiency and quality.

14.3.6. Check Your Understanding¶

Let's assume we updated isPalindrome to be case-insensitive (e.g. isPalindrome('Radar') returns true).