I am the only person on my team that use TDD. How do I make them to use it?

I am annoyed that when I pull, someone's code will break my tests and I am the one who has to fix them.

Will using github, fork and pull request solve this problem, so that they need to pass the test before the pull is accepted?

I am not the project manager and I can't seems to convince her to use it.

  • 11
    "someone's code will break my tests" did you consider a possibility that this indicates your design and / or tests are just too fragile?
    – gnat
    Apr 12 '12 at 7:20
  • 1
    Closely related: programmers.stackexchange.com/questions/44145/… Apr 12 '12 at 7:22
  • 2
    Perhaps start creating integration tests. Those are harder to break, as the input/output should (almost) always be the same. Once everyone is getting used to this, add unit tests as integration tests are a bit slow when running all of them. On a side note: If I were a PM of some small project (like less as 2 months or so), I wouldn't like it if the devs spent time writing tests also. The project needs to be finished and writing tests is good, but takes time and on such small projects, chances are small you do a lot of maintenance in the project time.
    – Jan_V
    Apr 12 '12 at 7:43
  • 1
    Devs should persue writing robust and stable code and tests can help with this. We aren't even telling the PM's we are writing tests, as it's none of their concern. We write them to ensure our code still works the same as 5 months ago. Also, you shouldn't see it as real 'tests' it's more of an insurance, or helper, or checker. When one says 'we are writing tests', one could get confused and think this is some task a tester should do.
    – Jan_V
    Apr 12 '12 at 7:48
  • 2
    Also very similar to: programmers.stackexchange.com/q/141468/39178... and I'm still looking for some good arguments. The problem is that you really can't change people's minds if they aren't open to change or if they feel that what they already do is good enough for them.
    – S.Robins
    Apr 12 '12 at 9:36

10 Answers 10


The way I see it, the only way to convince for anything about tests is to demonstrate that they are useful - ie that test failures help to find and fix bugs.

The way you describe the problem though, looks like this is not the case here. Look...

...when I pull, someone's code will break my tests and I am the one who has to fix them.

If I understand correctly, you mean you have to modify tests. Well, that does not sound like test failures help to find and fix bugs does it? If tests don't help in finding bugs, it's pretty weak position to start convincing your colleagues - what could they expect to gain? tedious fixes in fragile test code?

This may sound like a dead end, but it really isn't. Your final goal (convince for TDD) still makes pretty good sense, don't drop it. Just re-focus your efforts on removing the obstacle you discovered.

Test failures that bother you now are essentially "false alerts" - meaning these are bugs in tests not in the code. Use these as an opportunity to improve tests, to learn how to make good reliable test design. Work on tests to make "false alerts" less frequent and to make it easier to discover real bugs in tested code.

As you discover real bugs, let your colleagues know and help them fix - and don't forget to point that these bugs are found by your tests. That will make a really solid ground to convince your colleagues.

It is worth mentioning that test design skills you develop at "preliminary" stage will most probably be needed again, if (when:) you finally convince your teammates to use TDD. Think of it...

...What would happen when test driven development is introduced to your inexperienced colleagues?

First thing to expect is that guys will start writing crappy tests and (horror!) even breaking good ones while learning. To help them find a way to do it right you'll need quite a solid understanding of good test design.

All the errors you find and fix in your tests now, will be repeated again and again by all your teammates when they begin learning. If (when!) that happens, you would better be prepared to quickly and clearly explain how to improve if you want them to remain positive about TDD.

  • 3
    Good answer, but I would mention that if nobody else is TDDing or even running the test suite, then a common scenario for breaking a test would be if someone made a change to the production code without changing the test to expect the change in behavior. Could be as simple as changing the wording in an exception message. They check in, OP checks out, tests break, hilarity ensues. You might consider a test that asserts an exact error message too brittle, but the contract for my last job defined a defect as any deviation from the stated AAT, and error messages were common defects.
    – KeithS
    Apr 27 '15 at 15:22

When I wanted to encourage the use of Test Driven Development I ran a Cyber-Dojo. With this sort of exercise, the emphasis is not on the code itself, but on the process of writing the code.

We spent an afternoon, in pairs, repeating the same kata, but under different conditions. We started with all groups doing one exercise at the same time. This provided a baseline.

We then discussed some of the basic principles of TDD, had everyone change partners and repeat the same kata. We repeated the same kata to de-emphasise the generation of code and instead concentrate people on the process of naming test cases and the Red/Green cycle.

Then we repeated the kata again, but roughly every 10 minutes one person in each group would move to another group, simulating the rather fluid team environments we often find ourselves in these days.

In the final iteration, we had both partners change every 10 minutes or so into different groups. This helped to demonstrate that with TDD, even the handover from one team to a completely different one needn't necessarily be too painful, since the project should only every be one Red/Green cycle from working.

The interesting thing was, there were few people who had done any TDD before the session, but what TDD knowledge there was rapidly spread until by the final iteration through the kata, most people were thinking in a TDD way or could at least appreciate why it might be beneficial.

People generally said that the afternoon was both fun and informative and we are now looking at other ways to use Cyber-Dojo at my workplace.

Cyber-Dojo, written by Jon Jagger, works incredibly well for this sort of exercise. It is a web based integrated environment for doing deliberate practice of TDD and learning about team dynamics. It has lots of kata's selected specifically to help people concentrate on the process of TDD and not the problem. It also supports a range of languages, from Python and Ruby to Java and C++.

The best thing is, after doing a kata you can then go back and look at the red/green progression (or maybe not *8') of each of the groups participating. It's traffic lights are a great way to visualise how the TDD process works.

If you want your own CyberDojo server, the whole project can be found at github and there is even a Turnkey Linux appliance virtual machine linked from there, which means that assuming you already have VMware player or VirtualBox installed, you can be up and running within a few minutes of downloading the appliance!

  • 1
    +1 for the cyber-dojo reference. Was not aware. Looks very interesting.
    – radarbob
    Apr 12 '12 at 14:51

If they resists TDD, it is ok. Many people (including myself) are having problems with writing unit tests first.

However, you should raise a question about having no unit tests at all, and the issue of unit tests breaking. Unit tests are a safety net that prevents lots of possible bugs, and allows code refactoring. Explain about higher code quality, and cleaner code.

I think the best would be to find a video that explains advantages of using TDD, and show it on a meeting.

If she refuses to listen, then you can try to go to someone above her, but that might not be very smart if your boss is so stubborn.


It's really hard to convince people to change their habits, but here are some things you can try:

  • Talk to the other developers and explain to them why you think TDD is a good idea.
  • Convince them (or at least some of them) to try it for a limited time
  • Try to establish some minimum requirements for working well as a team. They don't necessarily have to do TDD, but they certainly shouldn't be checking in code that is failing unit tests. This is a separate issue than convincing them to use TDD, and is much more important to address.
  • Try to convince management to enforce a trial period for TDD. You will have to be ready to provide some evidence on why this is a good practice and how it will save the company time and money in the future.

If none of this works at all, you might want to consider working somewhere else. There are plenty of other companies that where your life would be considerably easier.

  • 1
    Singapore is a small country, not much choices.
    – wizztjh
    Apr 12 '12 at 6:50
  • 6
    "If none of this works at all, you might want to consider working somewhere else." Or, just for the record, you might consider stop using TDD :). Apr 12 '12 at 7:14
  • 1
    +1 for the third bullet point. That is the real problem.
    – riwalk
    Apr 12 '12 at 13:17

There are 2 slightly different issues here: getting people to do TDD and people breaking your tests.

I'm not sure about the first issue, personally I find it an artificial way of working and not suited to all types of development. I'm all for having a good suite of unit tests, but I usually find it more efficient to write the code first and then the tests, since while writing the code my ideas are always changing, and it's a waste of time writing tests too early (IMO).

On the second issue, set up the project so that unit tests are run on check-in, so that other developers don't have any choice but to know they've broken a test.

  • This is a good point, they are 2 seperate issues. First, solve the "they break my tests" issue. Then work on getting them to do TDD.
    – ozz
    Apr 12 '12 at 13:09
  • +1 for "since while writing the code my ideas are always changing," and interesting observation. Maybe I'm the same way, and that's why I have a hard time writing tests first? Especially at the beginning of an experimental project.
    – Buttons840
    Apr 13 '12 at 19:58

As said in a lot of other "how should I convince X to use Y method/technology", my answer is always the same: by example.

Use it and have better (mesurable) results. Then make sure the others notice.


On an existing project, you don't. It's the same as if you'd be making changes to the way curly brackets are placed in legacy code because you dislike the indentation style.

  • it is a new project, I just started it this week.
    – wizztjh
    Apr 12 '12 at 6:48
  • Our last project became too big and buggy. So , i think it is a good idea to use TDD for this project.
    – wizztjh
    Apr 12 '12 at 6:49

Lots of good advice. And now, a bit more...

You must win hearts and minds (WHAM) one Luddite at a time. Forget about forcing it down their throats. Lots of object lessons over an indefinite (sorry about that) period of time. Eventually you will hit a critical mass, convince the "right" person(s).

Your constant and consistent enthusiasm & avocation for TDD is very important in a WHAM campaign.

You must turn the test-breaking and code changes into teachable moments, the lessons which matter for your co-coders. Make it personal. I.E. Do they care about a reputation for delivering above average clean code? Do they care about management ragging on them about code that is now late because integration testers gave them a reality check? Does Jack have a desire to modify some difficult code but is afraid of side effects?

Gather good examples of test-breaking as trapping coder-induced bugs. The coders will see changing tests as unnecessary work to irrelevant code; they must understand that the tests just covered their arses.

Find some code with global implications (some simple utility method), build some tests, then demonstrate that tests permit change w/out fear of earthquakes throughout the application. And I do mean to emphasize the emotional issue too!

Gather some simple time-to-clean-code examples (i.e. passed into production) and demonstrate that despite the extra effort for test coding, we got her done faster & with higher quality.

Warning: TDD is not a cure for and cannot overcome bad OO design and coding (but it definitely can expose it). Do not let the Luddites blame the testing code effort for their incompetence.


I'd try try again to convince the manager. From what you've written, I don't think you could convince your teammates to do TDD behind her back.

You have to speak her language. Manager tend not to be impressed with technology, but they understand the business language:

  • tests will save time during development, because instead of manual testing (trying to reproduce bug locally, playing with the rails console...) you will be running tests automatically

  • test will save a lot of time during application maintenance, when you can easily detect bugs whenever you change something. Explain that tests require higher initial investment, but they'll pay for themselves in the long run (maintenance of good tests is usually quick and easy)

  • and what will you do with the extra time? create moar stuff and make them moar money :)

As for programmers, try this argument (it worked for me, way back): "You're testing code anyway, with or without TDD. Only you do it manually instead of automating it. Smart developers automate as many things as they can."


On real projects with deadlines people want to focus on getting the work done with what they know. That's just human nature. And if you never learned TDD, you would be the same as her in this situation. I guarnatee it.

Why doesn't the garbage collection crowd love, learn, and live RAII? How could you champion automatic memory management but hold on to the old fashioned management for general resources like files, connections, etc? Because RAII is a technology they don't know, understand, and don't have time to use when they have a deadline that needs work done.

I bet you don't use RAII and aren't willing to learn and understand it for your current project. Same as your coworker who is not willing to learn and understand TDD.

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