No really. Write your tests first.

I'm doing a few days on testing and TDD in advance of my webinar on the topic this week

Let's talk today about the first D in TDD. Test Driven Development means that the tests are motivating the application code that you write. You write your tests first, then write your application code to satisfy them.

Yesterday I talked about how testing for behavior forces you to make explicit decisions about the design of your software up front, and writing your tests first does the same thing. I'm not going to beat that dead horse, but I am going to show you how writing your tests first will help you work much faster.

Manual testing is slow. Think about your typical debugging cycle:

1. Write some code
2. Switch over from your editor to the browser
3. Refresh the page
4. Set up starting conditions (click, click, click)
5. Execute whatever feature you're trying to build (click click click)
6. Inspect log output to determine what went wrong and where
7. Repeat

This is slow and tedious. As a software developer, you always want to tighten the feedback loop of whatever you're working on. If you're working with an automated test suite and unit testing your code, you can focus on one small problem (the function or method that you're testing) and get immediate feedback as you work. So in this case, your feedback loop looks more like:

1. Write some code
2. When you save your file, your tests immediately tell you if your function is correct
3. Repeat, or move on to the next function

It may not seem like much, but when you're repeating this cycle dozens or even hundreds of times per day, it adds up in a very real way.

Writing your tests first forces you to focus on discrete, clearly defined problems with explicit acceptance criteria, and tells you immediately if what you've done meets those acceptance criteria. It takes some practice to learn to think this way when you sit down at your editor, but the change is well worth it.

Tomorrow: How and when to deal with all those pesky side effects...

Next Up:
Dealing with Side Effects When Writing Tests

Previously:
Test for Behavior, not Implementation