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.

Practical deomonstrations help

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?"

Get to the bottom of it

HLGEM Answers (16 votes):

First you have to know why they aren't writing tests.

Tight dev schedules are often the reason, but you say you don't have that. Next reason is that with a large existing untested code base, writing tests probably seems overwhelming, a never ending job (like laundry and about as exciting). So human nature is to think, "that's too much to face. I'll skip it." Another reason could be that while they think tests are a good idea, they are not confident about how to start writing them, especially if they never worked anywhere that wrote tests. Another strong possibility is that they really don't see any value in additional work, even though they are giving lip service to the idea.

So how do you handle the different reasons?

Reason 1 is simple: show them an example of how it saves development time.

Reason 2: show them how many tests you have written in a year and what percentage of the code base it covers. Do the math to show how many more tests they could have at this time next year if they do this. Once they see that little bits of progress on a daily basis really add up, the whole idea isn't so overwhelming. If you can, pull the data out of the system, show them how many bugs were repeat bugs in the untested parts of the code and how many repeat bugs appear in the code with unit tests.

Reason 3: training, not just showing. Make them write tests in a training class.

Reason 4: this is the crux of the matter. First, pick a pain point, one of those bugs that has returned multiple times. When that comes in, this is the time to suggest to management that if they had unit tests on this item, it wouldn't keep coming back like a bad penny.

Another way to address reason 4 is to have management make it part of the process and mandate that code doesn't pass code review unless the tests also pass code review. Best to approach them with making this a policy right after one of those pain points or preferably right after you have had several in a matter of days.

We all like to think that as developers we self-manage (LOL), but the ambitious will care about what managment emphasizes. And the professionals who really do self-manage are already writing the tests. If you can't get management to care about best practices, then you will be fighting an uphill battle all the way and, you might want to assess if this is the right corporate culture for you.

Something for (almost) nothing

ElYusubov Answers (7 votes):

I would start by demonstrating the benefits of TDD. Try to showcase benefits of unit testing.

As normal human beings, developers are motivated by benefits. They don't want to do things that just create more work. Unit testing means less work. It means going out with friends more. It means having more fun because you don't have to spend every night coding till 11pm. It means going on vacations more with a peace of mind.

One of the biggest benefits of TDD is that you can refactor your program to a better design or just change the name of something ... and as long as that design doesn't break the tests, you can have 100 percent confidence that your change didn't break anything.

Another great case for TDD is creating unit tests for legacy code. This would represent one of the best ways to start refactoring out the evil. In the long run, this will serve to improve your knowledge of the code base, understand its strengths and flaws, spot hard-coded business logic in the code and give you a good start to improve the quality moving forward!

Good references for further reading:

Related: "When is it appropriate to not unit test?"

Find the original post here. See more Q&A like this at Programmers, a site for conceptual programming questions at Stack Exchange. And of course, feel free to login and ask your own.

