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:

• Roy’s string calculator
• Bank OCR

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?

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:

• Why You Should Write Unit Tests
• Motivation Visibility, and Unit Testing
• The art of unit testing, according to Roy Osherove

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.

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

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.

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.

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 🙂