No. You can’t !
As a manager the only bossy instruction you should give is :
“Don’t you ever shut down a crashing test ! Fix it now !”
If a test is broken and red, no one should ever take the initiative of putting a @Ignore in front of it. Or worst : keeping the test but deleting it’s content ! Or replacing blindly statements without knowledge of what the meaning.
Only For The Braves
The person who will be responsible for fixing this test will have to understand and correct it. Even sometimes rewrite it to reflect the new reality. This is harder than coding actually. It’s less rewarding. It’s sometimes underestimated. No ones look at the tests. But this is worth it. Because avoiding problems is better than fixing them latter during expensive manual tests campaigns.
It’s the essential nature of unit tests : break when something is wrong (remember last episode ?)
[Bye the way : it’s the same for compiler warnings. They are not decorations, they are a proof that something is wrong. You can compile, but you’ll have bugs. Is this what you want ?]
Wrong Direction
I once heard about a lead programmer who was tired that one of his numerous “quick fix” broke unit tests. What did he do ? He just commented them !
This is the worst attitude for a lead programmer. But why did he do that ? Because he ignores the importance of unit tests. No one explained it to him. He thought this was a gadget. Just red and green lights for those geeks. “I’m not a geek. I know the core business, not geeky things.”
This is a serious issue. And this is why this series should be handed to anyone thinking unit tests is just a gadget.
TODO
- Have your lead programmer (who cares) do a code review of your tests. See if some are empty or useless.
- If so, take some budget to really explicit tests and maintain them. This is a good way to reimburse your technical debt.
For the developers out there
Come on you everybody does it ! You shut up a broken test instead of fixing it. Why ? What happened then ?
