Time and time again, I talk with someone who writes tests, but they don't feel comfortable/productive writing tests first. First off, writing tests after the fact is 100 times better than not writing tests at all. But, writing tests first does have its benefits, and doesn't have to be difficult. I'm not going to talk about the merits of writing tests first. That debate is all over internet already. This post is for those that write tests and have the desire to write tests first.
A Walk-Through Example
A typical test looks something like this:
Everyone knows this well and fine, but when faced with writing a test first, it's not clear how to start. A knee jerk reaction is to start with the setup because it's the first fragment of code in a test.
How does one know what to write for setup? The answer is, you don't really know. You can't honestly figure out what setup should be without first knowing what the behavior is doing. So instead of starting with setup, start with the behavior.
It's pretty easy to be creative at this point. We want a public interface that reads simply and accurately:
Cool, so we just wrote the behavior and also got some insight on the design of our new feature.
We now know that we need to setup three things: a clerk of courts, and two partner/person objects. Let's not do that yet though. Instead, let's write the expectations and see what else it reveals about our design.
The question is, how do verify that two partners are now married? Here's one way:
Cool, so now we know we need a marital status on a person, and that ClerkOfCourts#marry is supposed to change that value.
Ok, now let's finish the boring part, the setup.
Cool, that was easy. Take note that it was obvious that we needed to pass marital_status as SINGLE, since that's what's expected to change in our results. We wouldn't have easily realized this without first writing the expectations.
Now you can write the code to make this test pass.
If you're writing plain old ruby objects, it's much easier to write tests first.
If you're writing something like rails controller tests, then you might not be familiar enough with all of the rails controller conventions and rspec/rails helper methods that make it easy to write your tests and your code. In a case such as this, you can start by writing pseudo code in your test. After that, you can research how you write a rails controller action and what helper methods rspec/rails offers for triggering the behavior and asserting the expectations. Then, replace your pseudo code in your test with what you find, and then write the code that makes the test pass.
That also might be too challenging. Sometimes coding requires a lot of trial and error in order to figure out how a framework really works the way you need it to. For these difficult cases, go ahead and write your code first, and then write the test. Eventually, you'll get familiar with the frameworks, and it will become clearer on how to write the tests first.