If you’ve ever dabbled in Test Driven Development (TDD), you’ll recognize this 3-step flow:

  1. Write the test first.
  2. Make the test pass.
  3. Refactor.

What took me a little more time to realize is that Refactor refers not just to the code you’ve written to make the test pass. It also refers to the test itself.

Another consideration: Have you considered whether your test really covers all the possible circumstances? If not, you may need to write another test, or add a second assertion.

For example, if it’s possible that zero is going to find its way into the method, have you tested for that? What about null? What about a negative integer, if your method receives and integer? Or, if you’re working with a range, and that range crosses zero?

In other words, when writing a first test my most common mistake is to assume everything will follow the “happy path”. What I often forget is to write a test for when things are not what I first considered.

To avoid this, here’s a tip I learned from Tonya Mork: Name your test method using this pattern:


Do this, and when you’re writing your test, you know exactly what you’re testing for. And you’ll also be more likely to ask yourself, what’s the next test I need to write for what the method should do when NotCondition.