Beautiful Code [14]
As we will see, a combination of things makes tests beautiful. Unlike code, I can't bring myself to consider any single test beautiful—at least not in the same way I can look at, say, a sorting routine and call it beautiful. The reason is that testing, by its very nature, is a combinatorial and exploratory problem. Every if statement in the code requires at least two tests (one test for when the condition evaluates to true and one when it evaluates to false). An if statement with multiple conditions, such as:
if ( a || b || c )
could require, in theory, up to eight tests—one for each possible combination of the values of a, b, and c. Throw in control loops, multiple input parameters, dependencies on external code, different hardware and software platforms, etc., and the number and types of tests needed increases considerably.
Any nontrivial code, beautiful or not, needs not one, but a team of tests, where each test should be focused on checking a specific aspect of the code, similar to the way different players on a sports team are responsible for different tasks and different areas of the playing field.
Now that we have determined that we should evaluate tests in groups, we need to determine what characteristics would make a group of tests beautiful—an adjective rarely applied to them.
Generally speaking, the main purpose of tests is to instill, reinforce, or reconfirm our confidence that the code works properly and efficiently. Therefore, to me, the most beautiful tests are those that help me maximize my confidence that the code does, and will continue to do, what it's supposed to. Because different types of tests are needed to verify different properties of the code, the basic criteria for beauty vary. This chapter explores three ways tests can be beautiful:
Tests that are beautiful for their simplicity
With a few lines of test code, I can document and verify the target code's basic behavior. By automatically running those tests with every build, I can ensure that the intended behavior is preserved as the code evolves. This chapter uses the JUnit testing framework for examples of basic tests that take minutes to write and keep paying dividends for the life of the project.
Tests that are beautiful because they reveal ways to make code more elegant, maintainable, and testable
In other words, tests that help make code more beautiful. The process of writing tests often helps you realize not only logical problems, but also structural and design issues with your implementation. In this chapter, I demonstrate how, while trying to write tests, I have discovered a way to make my code more robust, readable, and well structured.
Tests that are beautiful for their breadth and depth
Very thorough and exhaustive tests boost the developer's confidence that the code functions as expected, not only in some basic or handpicked cases, but in all cases. This chapter shows how I write and run this category of tests using the concept of test theories.
Because most developers are already familiar with basic testing techniques, such as smoke testing and boundary testing, I will spend most of the time on highly effective types of tests and testing techniques that are seldom discussed and rarely practiced.
7.1. That Pesky Binary Search
To demonstrate various testing techniques while keeping this chapter reasonably short, I need an example that's simple to describe and that can be implemented in a few lines of code. At the same time, the example must be juicy enough to provide some interesting testing challenges. Ideally, this example should have a long history of buggy implementations, demonstrating the need for thorough testing. And, last but not least, it would be great if this example itself could be considered beautiful code.
It's hard to talk about beautiful code without thinking about Jon Bentley's classic book Programming Pearls (Addison-Wesley). As I was rereading the book, I hit the beautiful code example I was