Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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!

share|improve this question
Those other 172 unit tests were done by a developer who left the company. sad :( –  lurkerbelow Jul 18 '12 at 19:57
Other than the numbers at the end, this sounds rather familiar... (>_>) (<_<) –  Izkata Jul 18 '12 at 21:32
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 Jul 19 '12 at 0:17
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. –  Spencer Rathbun Jul 19 '12 at 13:08
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. –  lurkerbelow Jul 19 '12 at 14:09

15 Answers 15

up vote 40 down vote accepted

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?

share|improve this answer
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. –  lurkerbelow Jul 18 '12 at 20:24
Picture's worth 1000 words and all. Showing that it saves time is more convincing than saying This should save time. –  R0MANARMY Jul 18 '12 at 20:25
@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. –  jimmy_keen Jul 18 '12 at 20:43
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. –  Robert Harvey Jul 20 '12 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. –  jimmy_keen Jul 20 '12 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.

share|improve this answer
Pity there isn't a way to upvote individual paragraphs; so many excellent points. Overwhelming alone is worth a few votes... :) –  sarnold Jul 19 '12 at 0:33
+1 for find the reason. –  Adrian Schneider Jul 19 '12 at 2:51


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.

share|improve this answer
I've just read both articles. Thanks for your input. Especially for giving some tips on my second question. –  lurkerbelow Jul 18 '12 at 20:37

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.

share|improve this answer
I'd just like to add that this is the method that worked for me. I do TDD religious, no if, no but, no however. When people work with me, they start to realise the benefit of it. –  Sleeper Smith Apr 10 '13 at 23:50
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. –  perfectionist Feb 25 at 15:14

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:

share|improve this answer
Recently I've delegated some work to another developer. It wasn't an easy task. (some interface to external module) Something around 50-60 hours of programming. We talked about that task and how he should start. I've shown him TDD. I've told him that TDD would match perfect because he do not have to use a running database, running webservices. He could concentrate on his own implementation. He was impressed by the power. The result? Three (!!!) fucking (sorry) unit-tests for around 20k sloc. –  lurkerbelow Jul 18 '12 at 19:56
Thanks for your input. I'll try to keep on poking my co-workers. –  lurkerbelow Jul 18 '12 at 19:59
@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 Jul 19 '12 at 12:50
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 Jul 19 '12 at 13:18
@gbjbaanb I've just had a quick "pair programming" unit-test session with the developer. He found 3 bugs in the first few minutes.. –  lurkerbelow Jul 19 '12 at 14:07

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.

share|improve this answer
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. –  R0MANARMY Jul 18 '12 at 20:28
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) –  lurkerbelow Jul 18 '12 at 20:34

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

share|improve this answer
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. –  lurkerbelow Jul 18 '12 at 20:44
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. –  Emmad Kareem Jul 19 '12 at 9:02

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.

share|improve this answer

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. :)

share|improve this answer

If you have done 1521 unit tests you also know how many bugs you caught. Tell them! Emphasise the fact that the test cases are a onetime effort. They can be used repeatedly to ensure that new bug fixes do not break existing fuctionality.

share|improve this answer

I have also struggled with similar problems during the years. One thing that definitely help along the way is the gamification of the problem.

I have written a small program that calculate how many tests each developer has written during the past milestone. The top one usually gets some geeky award - Clean Code Green Band for example. If we further extend this we can have a scoreboard that updates each developer's written tests count after every commit.

P.S. The program I have written was called TechnicalDebtCollector.

share|improve this answer

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.

share|improve this answer

Buy 200 copies of books of uncle Martin ( http://en.wikipedia.org/wiki/Robert_Cecil_Martin ) and have your coworkers find it on their desks.

Highlight where he says that having code tested at 90% means being sure that 10% may fail.

After reading those books, I refuse to fix a bug if there isn't a unit or integration test demonstrating it, and refuse to implement something if there is no acceptance test (be it unit test or other kind) that can prove I've done my work properly.

It is a matter of not wasting time and being clear about what is asked to me, so makes me a better developer.

If you are the younger in the team, this attitude may be good for your codebase, but not for your job :)

However, the "write test - write code - see test failing a little later each time" cycle is addictive, makes you feel better, makes you sleep better at night .. if you can sleep well at night without tested code, it means you are not motivated at all, not only about tests.

share|improve this answer
I'd +1 you if you at least reduced the prominence of shelling out for 200 books. The rest of your answer is good. –  Mark Hurd Jul 25 '12 at 7:56

If possible, think of a small but relevant framework to write and use internally. Unit tests are an easy sell when you are writing code that will be used by code. After actually doing that, the merit of unit tests should be a bit easier to sell. It only takes one 'fix' that turns unexpected tests red to convince sensible folks that there might be worth to tests.

all of that said, I am not yet at anything approaching full coverage of my projects.

share|improve this answer

If your team is using Eclipse, then you can make use of TDGOTCHI - a virtual pet that helps you raise your TDD practice. May sound like a bit of a gimmick, but it could also serve as a useful daily reminder to those who choose to ignore testing best practice.

From the site:

TDGotchi is hungry. Feed it some tests!

  • Make a test fail and then make it pass, TDGotchi is happy.
  • If your test run fails twice, TDGotchi is upset.
  • Refactor, rename, inline. That makes TDGotchi happy.
share|improve this answer

protected by Thomas Owens Mar 16 '13 at 17:00

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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