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? Leave a comment below.
I first experienced the joy of programming in junior high. But on the job, some of that joy was sucked away by seeing code my teammates were afraid to touch. Poor code led to fear, and fear led to our entire team being let go. I began searching for ways to improve code. I stumbled upon the first wiki, which was about Design Patterns, Extreme Programming, and Test Driven Development (TDD). I rediscovered joy on the job. I've now been doing TDD in Apple environments for 17 years. I'm committed to software crafting as a discipline, with the hope of raising you, my fellow programmers, to greater effectiveness and joy.
Please log in again. The login page will open in a new window. After logging in you can close it and return to this page.