Beautiful Code [130]
[] Another indication of JUnit's success and influence is that today there are JUnit-inspired frameworks for most modern programming languages, as well as many JUnit extensions.
JUnit is intentionally simple. Simple to learn. Simple to use. This was a key design criterion. Kent Beck and Erich Gamma took great pains to make sure that JUnit was so easy to learn and use that programmers would actually use it. In their own words:
So, the number one goal is to write a framework within which we have some glimmer of hope that developers will actually write tests. The framework has to use familiar tools, so that there is little new to learn. It has to require no more work than absolutely necessary to write a new test. It has to eliminate duplicate effort.[§]
[§] "JUnit: A Cook's Tour," Kent Beck and Erich Gamma: http://junit.sourceforge.net/doc/cookstour/cookstour.htm.
The official getting-started documentation for JUnit (the JUnit Cookbook) fits in less than two pages: http://junit.sourceforge.net/doc/cookbook/cookbook.htm.
Here's the key extract from the cookbook (from the 4.x version of JUnit):
When you need to test something, here is what you do:
Annotate a method with @org.junit.Test
When you want to check a value, import org.junit.Assert.[||] statically, call assertTrue(), and pass a Boolean that is true if the test succeeds
For example, to test that the sum of two Moneys with the same currency contains a value that is the sum of the values of the two Moneys, write:
@Test
public void simpleAdd() {
Money m12CHF= new Money(12, "CHF");
Money m14CHF= new Money(14, "CHF");
Money expected= new Money(26, "CHF");
Money result= m12CHF.add(m14CHF);
assertTrue(expected.equals(result));
}
[||] Another indication of JUnit's success and influence is that today there are JUnit-inspired frameworks for most modern programming languages, as well as many JUnit extensions.
If you have any familiarity with Java, those two instructions and the simple example are all you need to get started. That's also all you need to understand the tests I will be writing. Beautifully simple, isn't it? So, let's get going.
Beautiful Tests > Nailing Binary Search
7.3. Nailing Binary Search
Given its history, I am not going to be fooled by the apparent simplicity of binary search, or by the obviousness of the fix, especially because I've never used the unsigned bit shift operator (i.e., >>>) in any other code. I am going to test this fixed version of binary search as if I had never heard of it before, nor implemented it before. I am not going to trust anyone's word, or tests, or proofs, that this time it will really work. I want to be confident that it works as it should through my own testing. I want to nail it.
Here's my initial testing strategy (or team of tests):
Start with smoke tests.
Add some boundary value tests.
Continue with various thorough and exhaustive types of tests.
Finally, add some performance tests.
Testing is rarely a linear process. Instead of showing you the finished set of tests, I am going to walk you through my thought processes while I am working on the tests.
7.3.1. Smoking Allowed (and Encouraged)
Let's get started with the smoke tests. These are designed to make sure that the code does the right thing when used in the most basic manner. They are the first line of defense and the first tests that should be written, because if an implementation does not pass the smoke tests, further testing is a waste of time. I often write the smoke tests before I write the code; this is called test-driven development (or TDD).
Here's my smoke test for binary search:
import static org.junit.Assert.*;
import org.junit.Test;
public class BinarySearchSmokeTest {
@Test
public void smokeTestsForBinarySearch()