This is about speed. The more I trust the tests over a section of code, the more fearless I can be with bold refactoring. Fearless refactoring means I don’t spend time checking correctness. That’s what the tests are for! Instead, I can focus completely on good design.
So how can you increase confidence in your test code?
The Second Law keeps test code minimal. We write tests that contain no more than they need.
How long should a unit test be?
The ideal for which I strive is: three lines. Arrange, act, assert.
In practice, I separate those three sections with blank lines. This allows a little wiggle room for each section to grow slightly. But when any single section grows past three lines, I get an uncomfortable feeling. That is, if I have more than three lines in the arrange, act or assert sections, I pay close attention.
The discomfort leads me to ask two questions:
The rule of refactoring is to start from green (tests passing) and end in green.
But your science mind is churning. How do I know I the refactored test code still fails when it should? It seems too easy to weaken a test by mistake. For example, let’s say I delete an assertion. The test still passes! Isn’t this a recipe for failure?
The thing to understand is that almost all the time, refactoring tests is nothing more than Extract Method. And the method you extract is short — just a few lines. Nobody starts doing stupid things just for the sake of breaking TDD.
But unit testing is about confidence. Sometimes I still get a nagging feeling that asks, “Is this test still correct?”
There’s a simple way to test the tests: Deliberately break something in production code. There are various ways to do this.
Which should you choose? The one you have bad feelings about.
Doing any of these things should cause a test to fail. If not, it means one of two things:
Practicing TDD, writing short tests, keeping test code squeaky-clean… These things can help you move faster. Your increased confidence in the test code will help you refactor quickly and boldly. Skillful refactoring will gradually make your code easier to read, maintain, and extend.
When in doubt, break something and confirm whether your tests protect you.
But… what if the test code you need just isn’t simple? What if a test is too intricate? What if a test contains conditionals or loops? In coming posts, I’ll illustrate a problem I face in the TDD sample app, and how I solve it.
How confident are you in your current unit test suite? How will you increase that confidence? Click here to leave a comment.
Jon is a coach and consultant on iOS Clean Code (Test Driven Development, unit testing, refactoring, design). He’s been practicing TDD since 2001. You can learn more about his background, or see what services he can bring to your organization.