This is secret unit testing tip #5. Want more? Register to the webinar.
What are tests for?
(if you still think that the question is stupid after reading this, let me know in the comments).
Obviously they are there to protect you from bugs. When a bug creeps in, the tests will catch it, and you’ll fix it.
But that’s not all they do.
The “fix it” part can take a while. It can become shorter if you write your tests correctly. And you can start with naming the tests clearly and consistently.
Imagine this: you’re working on component D, after completing components C,B and A in the last few months. You add some code, run your tests, and BANG. 3 tests for A break. Lucky you had those tests!
So what do these tests do with A? Let’s take a look: they are called test13, test15 and test15Null. Hmm.
Do you still feel lucky, punk?
Tests are pieces of information. They can help you shorten the distance between “found the bug” to “fix the bug”.
Test names should be helpful, describing what the test is about, and what makes it different from other tests. When you see a couple of tests failing, while other pass, it should set you with context, and that already puts you in the place closer to the solution.
The naming should be consistent, so if someone else takes a look at your test, it will resemble the way she names tests. I prefer the “method_scenario_result” convention, but you can find your own – it doesn’t matter as long as it works for the team.
The name is almost the most important part of the test. When I work with people who start out writing tests I make them tell me what they are going to test. And that requires thinking ahead of coding, which is the best bug prevention method I know. That’s why TDD is so good for you.
Next time you see a test15, rename it to something that will help you three months from now.
PS This is just one topic from what I’m going to cover in my next webinar “10 secret unit testing tips to become agile.” Want to get the rest? Register to the webinar.
