| I'm CTO at a bootstrapped agency that has now 30+ ppl, and I couldn't agree more with the author. Sure thing that you can use your authority to force ppl, but should you? Smart people are hard to come by but once you have them you should let them work, and when you tell them how to do their job you implicitly assuming that you know better. Besides if you force them you achieve nothing but some brain-dead tests that are going to hunt you later and getting a budget to "rewrite tests" is a fairytale. The art here is to build a culture that embrace the test as a powerful tool. So newcomers are quickly seeing benefits and start to write the tests in right places, not for the sake of an artificial metric. Besides, there are plenty of places where having high coverage is going to be a waste of time:
- throwaway prototypes,
- heavy UI code full of animations - they need to look right that is hard to test,
- infrastructure code if you have just a few servers of a particular type,
- customer projects with unreasonable deadlines that are not going to be touched again, So having your team that writes tests is a hard job and using PR policy won't help much. The things that worked for me were:
- write tests that make sense your self in early stages of the project
- pair with your employees and write tests with them,
- do peer reviews and suggest what could be tested and why it make sense. |