Unit tests are like painting. A good artist knows what he wants and when he has it. He also knows the “why”. Same for (good) developers/managers.
Having The End In Mind
First : you must know why your team is doing unit tests.
In fact you must follow a business logic more than a method or a trend.
Don’t encourage unit testing just because “others do it” or “it’s like that”.
Think about it. What does it mean ? Why are you unit testing ? Why do you take some of the money you have to put it in a code that won’t be in the final product ? Is it worth it ?
Take some time to stop and think about what you have done and what you want.
Software quality ? Ok, it’s a good reason. And why doing good-tested software ? To make your users life easier ? To gain market share ? To avoid costly support ?
They Don’t Really Care About Us
Your users don’t care about your software actually.
They don’t care about unit tests, integration tests…
They wan’t to do stuff that works. And they maybe need your product.
This is why you do unit tests : to make good software, to have people use it, so you’r company can sell it.
Just like the automated inspections in an assembly line : you must be sure you don’t sell rotten products to your clients. That’s the reason. It’s even better than adding features.
People want features that work.
Are We There Yet ?
Second : your must know when you have reached a good quality.
Sometimes while doing unit tests, you feel like you have it all. You have done all you can do automatically. You can’t go farther.
That’s when to stop.
Easier said than done.
This is why as a manager you must take the pressure off your team when they are doing unit tests. You must let them think.
Are they done with it ? No ? Let them finish so you can be sure this part is stable and clean before moving on. Besides developers love doing good job, not jumping from an unfinished feature to the next.
Take time to stop and think.
And stop writing tests when you’r done. But never before. And not because of budget. If you are short on budget, prefer to limit the number of features, not the quality of the existing one.
TODO
- Challenge your team. Ask them if they covered all their main methods. Ask them what’s the last time they reviewed the tests.
- And if all that can be tested automatically is not, let the pressure off and let them implement the remaining tests.
- Of course this will be a budget nightmare if you have not encourage them to write test along the path…
For the developers out there
