We're working on a large product which has been in production for about 5 years. The codebase is.. erm.. working. Not really well but it is working. New features are thrown into production and tested with a small QA. Bugs are fixed, etc. But no one, except me, is writing unit-tests. No one uses the power of "tracking" down bugs by writing unit tests to ensure this special bug (test case) would never, ever occur again.

I've talked to management. I've talked to developers. I've talked to everyone in the whole company. Everybody says: "Yep, we must write more unit-tests!" That was about a year ago. Since then I have forced introduction of pre-commit code review (Gerrit) and continuous integration (Jenkins).

I held some meetings about unit-tests and I also showed the benefits of writing unit-tests. But no one seems to be interested.

Q1: How do I motivate my fellow co-workers to write unit-tests?

Q2: How do I stay motivated to follow my personal code quality standards? (Sometimes it' s really frustrating!)

PS: Some frustrating facts (reached in 1 year):

  • Total unit-tests: 1693
  • Total "example unit-tests": around 50
  • Done by me: 1521

Edit: Am I expecting too much? Its my first working place and I'm trying to do my best.

Edit 2: Based upon all answers I've made a small checklist for myself. I've talked to two developer in private and we had a good and honest talk.

One of them told me, like Telastyn said, that he is really uncomfortable with unit-tests. He said that he would like to be "more professional" but he needs a kickstart. He also said that our unit-test meeting with all developers (around 9-11) was good, but it was too crowdy. Meh. Some critics for me, but I'll learn from that. (see answers below concering tdd kata meetings!)

The other one said that he is not interested in writing unit-tests. He thinks that his work is good enough for his salary. He don't want to put more effort in. I was quite speechless. Typical 9-5 "worker".

Next week I'm going to talk to the other developers.

Thanks for your great answers (so far!) and your support. I really appreciate it! I'ved learned a lot, thank you very much!

  • Were the other 172 unit tests done by you in previous years or is someone else doing unit tests that you are trivializing their contribution?
    – JB King
    Commented Jul 18, 2012 at 19:54
  • 16
    Those other 172 unit tests were done by a developer who left the company. sad :( Commented Jul 18, 2012 at 19:57
  • 6
    Please keep talking numbers. How many bugs discovered in the last year, how many of those were discovered, and how many prevented by Unit Tests. How much time writing tests (1521 in a year by one person) vs "Doing real work" (in terms your workmates probably think). Do they perceive UT as beneficial, or a waste of time. i.e. Show me the Money.
    – mattnz
    Commented Jul 19, 2012 at 0:17
  • 1
    Out of curiosity, do your coworkers have an alternative debugging strategy? TDD is useful for proving that something works as expected, but not so much for unknown issues. They may be comfortable with just hooking in a debugger. Commented Jul 19, 2012 at 13:08
  • 3
    Hooking a debugger for testing purposes is right, but it does not ensure that the code would work in a few days/weeks/months and that's the real issue. Commented Jul 19, 2012 at 14:09

10 Answers 10


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 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; simple task to implement using a test first approach as opposed to no tests. Depending on how complex the task is, non-test approach should usually be slower, especially with incremental required changes:

Edit: OP's comment made me realize there's even stronger argument at his disposal - regression aka returning bugs. Those kind of situations are perfect examples demonstrating how benefical unit tests can be. People like numbers - like I said, telling "unit testing is good" might not be convincing, but arranging data like below might surely be:

  • time spent to implement feature (no tests were written; I assume this happened often so it should be relatively easy to find such example)
  • estimated time to implement feature with TDD (or even tests after approach; doesn't matter - what's important is presence of unit tests)
  • time spent resolving the bug on untested vs tested code

One thing to warn you about (this migth be obvious but is worth noting): outcome bias - make sure you don't select example where the only way of spotting bug with test was to write test for that bug. Usually, nobody knows bug will occur upfront, but it's tempting to say "man this bug would be trivial if we had test for X" - it's easy to find a winning tactic for a war after it has ended.

Outcome of those examples should be simple question - if you could spent x-hours developing feature Y, why would insist on doing it in 2x?

  • Thanks for your input. I think I'm going to schedule a TDD meeting with katas.. Two developer per meeting so I could possible help out. Yeah, the software "works". But a lot of bugs are "returning" ones. If someone fixes something in module A maybe submodule A1 wont work anymore in some cases. Those bugs are (mostly) not found during QA. That's such a waste of time. Writing unit-tests: (maybe) 1h. Getting a bug report from customer, analyse, planning, fixing, code review, building, hotfix delivery, etc.. about.. 6-8h. Commented Jul 18, 2012 at 20:24
  • Picture's worth 1000 words and all. Showing that it saves time is more convincing than saying This should save time.
    – Roman
    Commented Jul 18, 2012 at 20:25
  • 4
    @lurkerbelow: the returning errors (or, regression if you like) argument is a very strong one. Think about arranging existing problem or bug you've spent way too much time on in those examples, and show how having tests written could have helped.
    – k.m
    Commented Jul 18, 2012 at 20:43
  • 10
    In my experience, writing tests does not reduce development time, at least not upfront; it increases it. It does, however, produce more reliable, better designed, more easily maintainable software. Commented Jul 20, 2012 at 5:44
  • @RobertHarvey: you're right about that, "development" is poor wording choice on my side. I couldn't come up with anything better describing process of designing, implementing, releasing and maintaining a piece of software. UT in the longer run, do shorten/simplify this process and that's what I had on mind.
    – k.m
    Commented Jul 20, 2012 at 22:37

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

Tight dev schedules is 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, so 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 have never worked anywhere that did write them.

Another strong possibililty is because they really don't see any value for more work even though they are giving lip service to the idea.

So how do you handle the different reasons?

Reason one is simple, show them an example of how it saves development time.

Reason two - 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 is 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 the 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 to them that they should care about and the professionals who really do self-manage are already writing the tests. If they neither care about being professional and doing best practices because they improve the product or care how about impressing managers to get promoted (or not fired), then you might consider if this is the right place for you. If you can't get management to care about best practices, then you will be fighting an uphill battle all the way and again, you might assess if this is the right corporate culture for you. While every work place has its problems (and running away isn't always the answer), this place doesn't seem to fit your level of professionalism.


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% 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:

  • 3
    @lurkerbelow, ok, and now your next task is to monitor those sloc for bugs - keep an eye on your bug tracker and the code changes that arise. If there are no bugs, then your colleague has a point. If there are loads, then you have a point. Either way, you will have some empirical evidence.
    – gbjbaanb
    Commented Jul 19, 2012 at 12:50
  • 3
    The fact that you can prove your changes didn't break something else is a BIG power in my view. The immediate response of working software is useful, too. Unfortunately, some folks will never want to attempt the startup learning. Ironically, that limited startup for immediate gratification is too much in our immediate gratification culture....
    – Jennifer S
    Commented Jul 19, 2012 at 13:18

This seems like a big case of lead by example.

There are two inherent aspects of human nature you are fighting:

  • Creative people don't like process.
  • Most people don't like external negative judgments on their quality.

It is very hard to fight this with lecturing, management declarations, or even logic. You have to win taking advantage of an alternative aspect of human nature.

  • People mimic the behavior of the best employees

If the best employees use TDD and it works, the process will expand. If they don't, it won't. If you need to convince anyone, it's the top 1 or 2 employees.

  • It is worth noting that without already being in a culture that embraces TDD, your colleagues are not driving you forward to become better at it. If they see a weakness in your method, they'll call it out and say "so it'll never work". To lead by example, you have to invest your own time and effort improving your methodology. Commented Feb 25, 2015 at 15:14


I think I bookmarked that link from a Jeff Atwood article some time ago [edit: yep, here it is]. Old but relevant. Due to these benefits and others that will undoubtedly be outlined in other answers, your programmers should be able to motivate themselves! It will allow them to work more efficiently and thus make their job a bit easier. Who doesn't want that?

In regards to your 2nd question: your sense of ownership and pride in your code quality standards should keep you going with them. Think about what you want to accomplish by having such standards and who benefits from them. My personal code standards can be frustrating as well, but I always feel like I'm doing the world/company/team a favor by implementing them. So I don't think you're trying to do too much - results will vary place to place but at least you're making the effort.


Ask them.

You say that people have been told, and agree that they should write more tests. Why are they not?

It may not (often times isn't) a matter of simple motivation. They might forget about them. They might feel under time pressure. They might not know how to write good tests. They might think you're so good that they don't need to do it. Knowing the root cause will help you solve the problem better.

  • 6
    In theory it's a good idea, but it's hard to answer the question So if you know unit tests are good, why aren't you using them? without sounding like like an asshole eg I don't know how or I don't have time or I'm smart my code should work. That situation would normally make people defensive and you'd get poor results.
    – Roman
    Commented Jul 18, 2012 at 20:28
  • 2
    I do not want to point on other peoples "mistakes". Maybe I should have a chit chat while being in private, e.g. having a beer or ten. Time Pressure isn't really a point. We have a great schedule with enough buffer time. (150%+ estimated) Commented Jul 18, 2012 at 20:34

You would think the unit tests would be the selling themselves. I don't know how your company works, but when there is an issue during a production rollout we work it until it is fixed. It doesn't matter if it happens at 2 AM on a Sunday morning. This is very rare for us, but when it does, it sucks.

I would start by asking them how many times they had to get up in the middle of the night to fix some major issue that could have easily been found automated testing. That is not to say automated testing will fix everything, but it should help reduce that.

The second big seller is the QA cycle. Prior to the start of TDD in my company we would push new releases to QA to test every week. They would create a pile of bugs off that release, we fix those bugs and push another release. Repeat until finished. The first project we did TDD didn't require a push out to QA until several weeks later. And the number of bugs found has been very, very small. 10% compared to a similar project. Do you have anyway to compile those stats for your team?

The other big selling point was how the code looked after TDD was embraced, it was easier to read, because we wanted to make it easier to test. Show a comparison between code written for unit tests and code not written.

Finally, show them how they will be able to refactor code with confidence.

Keep all that in mind when you don't feel like writing tests. :)


I'd like to expand upon HLGEM's answer, especially this section:

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, so I'll skip it.

I've found that code I write with the intention of writing tests is significantly better code than code I write without the intention of writing tests; asking myself How will I test this function? forces a better design of each and every function. (Less reliance on global or semi-global data; IO separated from computation; functions do only one thing; consistent error handling; and so forth.)

Trying to put tests on old code that was not written with testing in mind may be beyond frustrating.


I've used a few techniques:

a) set up an automated build. When someone breaks something that you tested, show them how the test detected it and how bad the bug would have been.

b) Do complex projects with tests (you drive). This will show how few bugs exist in that project. I had one complex server interaction project that started working flawlessly. It never failed QA and all integration tests went 100% smoothly. That system became known as highly stable and overall management was happy with it. What you do in these situations is present how unit testing enabled that.

c) Pull in one person at a time. The one who listens to you. Take on bugs and show how tests expose deep and difficult problems. This helps. It's never an easy thing. But once you get a fan, he will only help. It's a domino effect.

  • c) looks good for my case
    – Nakilon
    Commented Nov 13, 2015 at 17:15

Bake unit testing in the process. If a bug shows in production that is too obvious to catch in unit test then this guy takes the blame. Assign people to write each test they make. Randomly pick cases and watch the execution of few cases every week. By doing unit tests, people will ask about the requirements and eventually tie the requirements to development and hopefully develop software that both required and works :)

  • Thanks for your input. You stated out that writing unit tests enforces the developer to think a bit further about requirements, etc. That is sometimes really a problem. Feature A is implemented and working. QA tells dev that test case x is not working because he hasn't thought of possible side effects. We're using continous integration to enforce our unit-tests. All tests are run if anybody checks something in. So we would catch possible side effects before shipping to QA/customers. Commented Jul 18, 2012 at 20:44
  • 1
    Unit testing is different than integration testing. I believe that the developer is also responsible for integration testing and QA role would be to make sure that everything is in order (to the extent of verification they can perform). Of course there could be problems in versions, missing pieces, distribution of code to servers, etc. that can't be caught early but these have nothing to do with requirements or unit testing.
    – NoChance
    Commented Jul 19, 2012 at 9:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.