Red, Green, Refactor

It’s all very well saying that you should write the test before you write the code, but how do you write that test? What should the test of some nonexistent code look like? Look at the requirement, and ask yourself, “If I had to use code that solved this problem, how would I want to use it?” Write the method call that you think would be the perfect way to get the result. Provide it with arguments that represent the input needed to solve the problem, and write a test that asserts that the correct output is given.

Now you run the test. Why should you run the test (because we both know it’s going to fail)? In fact, depending on how you chose to specify the API, it might not even compile properly. But even a failing test has value: It demonstrates that there’s something the app needs to do, but doesn’t yet do. It also specifies what method it would be good to use to satisfy the requirement. Not only have you described the requirement in a repeatable, executable form, but you’ve designed the code you’re going to write to meet that requirement. Rather than writing the code to solve the problem and then working out how to call it, you’ve decided what you want to call, making it more likely that you’ll come up with a consistent and easy-to-use API. Incide....²