This Q&A is part of a weekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 90+ Q&A sites.
lurkerbelow is the only developer at his company writing unit tests. Management, developers, everyone says they want to write unit tests, but nobody does. To bring developers into line, lurkerbelow has introduced pre-commit code review (Gerrit) and continuous integration (Jenkins). Not working. “How do I motivate my fellow coworkers to write unit tests?” he asks.
jimmy_keen Answers (32 votes):
I noticed that talking about TDD hardly works. People like to see raw results. Saying that “writing tests will reduce development time” is most likely true, but it might not be enough to get anybody convinced.
I was in a similar position (well, not as bad as yours), and it kind of resolved itself when people started working on my code (note: my code was unit tested, others’ not so much). When something stopped working, natural follow-up after local investigation was to ask me what could be the reason. Then we sat, we ran unit tests and saw what happened. If tests were passing, most of the time problems were in the new, untested code. If not, tests were usually able to spot the problem (or at least point us in the right direction). We fixed the bug, tests were up again, everybody was happy.
Long story short, a few situations like this transpired and 2 more developers became TDD/testing enthusiasts (there are still a few more to go, but it looks promising).
As for advice, you can give a go with TDD kata; a simple task to implement using a test first approach as opposed no test. Depending on how complex the task is, non-test approach should usually be slower, especially with incremental required changes:
Related: “What are effective ways to introduce the concept of code kata into the workplace?”