A colleague is unwilling to use unit tests and instead opting for a quick test, pass it to the users, and if all is well it is published live. Needless to say some bugs do get through.

I mentioned we should think about using unit tests - but she was all against it once it was realised more code would have to be written. This leaves me in the position of modifying something and not being sure the output is the same, especially as her code is spaghetti and I try to refactor it when I get a chance.

So whats the best way forward for me?

  • 3
    The aversion to write unit tests has maybe less to do with your colleague than with the systemic overhead of common unit test implementations.
    – mario
    Commented Feb 3, 2011 at 10:53
  • 2
    @james: Please see my response to @m.edmondson. Commented Feb 3, 2011 at 12:17
  • Good!! Less competition for you!!
    – user1551
    Commented Feb 3, 2011 at 12:22
  • @Jonathan - fair enough, I stand corrected
    – ozz
    Commented Feb 3, 2011 at 14:02
  • @m.Edmondson - new job.... it was a little tongue in cheek that part of my comment, but it does sound like a sucky place to work, old tech, devs not willing to use a sensible dev practice.
    – ozz
    Commented Feb 3, 2011 at 14:04

12 Answers 12


She is not aware of the benefits of unit testing and that's what you need to change:

  • Her awareness.

You will have to prove her it will improve her work not just yours. That will be difficult, she will probably try to focus on every negative aspect she could find if she is afraid of change.

You can try to discuss with her about all the benefits and listen to all her counter arguments. Wait until she finish to talk before starting to talk yourself.

To prepare yourself, you should look on P.SE or Google for all things management or developers are worried about unit testing and compile the answers you will use during your discussions with your colleague.

Just listening to her and provide proof it will improve her work will help you a lot. You prove you are concerned by her opinion, and you provide her with all data she needs to analyze the situation and eventually change her mind.

  • 21
    Love the list of one item. +1
    – Armand
    Commented Feb 3, 2011 at 11:15
  • 1
    This answer would have been perfect if you stopped right after the list. +1 :)
    – user131
    Commented Feb 3, 2011 at 12:40
  • Hey Tim congratulation for your 2nd position in SO elections!
    – user2567
    Commented Feb 3, 2011 at 12:47
  • 7
    I felt like that list deserved its own pie chart.
    – Tomas
    Commented Feb 3, 2011 at 15:16
  • You might also need to change her willingness to ship bugs. Some defect avoidance might make better testing more important.
    – stonemetal
    Commented Feb 3, 2011 at 16:50

Write a unit test (don't tell her)

Wait till the thing breaks, Let her do manual tests for two days, then pull out your unit tests and find bug in three seconds.

Take cover...

  • 1
    +1 For indicating that bugs are inevitable and to take cover.
    – Neil
    Commented Feb 3, 2011 at 10:48
  • +1 Writing a full suite of unit tests for one particular piece of the code may expose enough problems with the code that demonstrate the benefits anyhow. I remember watching a presentation on how unit tests can be used to maintain interface/API specifications/behaviours through a complete code re-write... Commented Feb 3, 2011 at 13:12
  • 3
    @JBRWilkinson: Merb (former Ruby web application framework) did exactly that. Not with unit tests, though, but with functional tests. The architecture had grown "organically", and while the framework was nice to use, it wasn't nice to maintain and extend. And since maintainability and extensibility were actually two of the major selling points over its competitor Ruby on Rails, they obviously needed to do something about it. And what they did was literally to rm -rf the source and unit test directories, keeping only the functional tests, and simply get them passing again one by one. Commented Feb 4, 2011 at 1:48

Automating otherwise manual tasks should appeal to any programmer.

So she's not "writing more code" she's doing less manually.

  • 1
    depends if you have a test team that does all that for you :)
    – gbjbaanb
    Commented Aug 10, 2011 at 12:30

(One of) the point(s) of automated tests is repeatability. If you do a quick test by hand, you may get it done faster than writing the same as a unit test (for a unit testing beginner at least - anyone experienced in unit testing can churn out tests pretty fast).

But what when tomorrow, or next week, a small (or big...) change is made to the code? Would your colleague happily repeat the same manual tests over and over after each change, to ensure that nothing is broken? Or would she prefer "code and pray"?

The more the code is changed, the more the unit tests pay back your initial investment. It doesn't take long to get on the positive side, even without the tests actually catching any bugs. But they regularly do that too - at this point, they become invaluable. And once someone experiences that feeling of safety, and confidence in one's code that a successful unit test run gives, there is usually no turning back.

If she is sort of convinced but afraid to venture into the new area, offer her a pair programming session to write her first unit tests together. Pick a class which is not too difficult to test but complex enough so that it is worth testing.

However, if she isn't convinced, you may need to get on collecting hard facts. Such facts may be

  • defect rates in code written by you vs hers
  • writing a set of unit tests against her code and documenting the bugs found.

Collect some such data, then politely show her the results. If these are still not enough to convince her, you may need to discuss the problem and share your collected evidence with management. That should only be your last resort, but sometimes there is no other way.

  • Highly unlikely - although its not unknown to have test plans (excel documents) pages long
    – billy.bob
    Commented Feb 3, 2011 at 10:41
  • @m.edmondson, yes, that was just a rhetorical question :-) Commented Feb 3, 2011 at 11:43
  • +1 for repeatability. I am an aggressive refactor(er), and I love the fact that I can find regressions very quickly when I completely rewrite a section of code.
    – Michael K
    Commented Feb 3, 2011 at 14:07

Write a basic test coverage for the worst bits of her code, rafactor it based on those tests, then make a case with management that unit testing on continuous builds will improve productivity. Changes come easier when mandated by an employer rather than evangelised by a single developer.

Don't know how to express this properly, but: if you're refactoring her code "when you get a chance"... well, she probably thinks you're a bit of a douche for involving yourself in "her business", so is less likely to listen to you with an open mind. In my experience, people become attached to what they've done - even when it's not terribly good.

  • We're on .NET 1 (A joke I know) - can unit tests be implemented here?
    – billy.bob
    Commented Feb 3, 2011 at 10:43
  • 1
    @m.edmondson: Something like NUnit perhaps? (nunit.org) Commented Feb 3, 2011 at 10:47
  • @dr Hannibal Lecter - Yea I think we've got a copy of that somewhere Ill see if I can find it
    – billy.bob
    Commented Feb 3, 2011 at 10:50
  • 4
    unit tests don't need to use a specific suite to be effective. I've written them just in python making calls against a c++ program and verifying the values received. a framework helps, certainly, but its not a necessity.
    – TZHX
    Commented Feb 3, 2011 at 10:59

To play devils advocate: she has a point. I usually put it as:

Automatic tests solve the problems of to much code with even more code.


  • study about the correlation of fault rate and OO metrics, headline result: "After controlling for size [of the class] none of the metrics we studied were associated with fault-proneness anymore". (The study discusses class size. Does this effect extend to the size of the code base? Probably. in my opinion)
  • Empirically, large projects tend to go forward slowly. "5K lines overnight in a new project" vs. "10 lines / day on a large one". Does that indicate a "resistance" to change increasing with the size of the code base?
  • We always proclaim "there is no best language, it depends on the problem." One key requirement is modeling problem entities and operations easily in the language of choice. Doesn't that suggest choosing a language where expressing your problem is more elaborate is worse, and doesn't that again correlate with the final size of the code base?

Now, there are a few arguments to fire against that easily. Let me adress the ones i can think of:

  • size vs. simplicity: Of course it is possible to make code shorter and worse. However, that's only a problem when comparing code bases with different brevity-vs-simplicity ratios, for the discussion one can assume we could somehow control for this factor.

  • Unit tests pressure you to reduce dependencies, and I empirically agree that reducing depencies can mitigate code size problems (in the sense that of two codebases of similar size, the one with more interdependencies is worse). However, while reducing dependencies betwwen production code units, it introduces coupling between the test and the unit itself.

TL;DR: I don't argue unit tests are bad; I ask: is there a break-even point where tests hurt that is correlated to the amount of code?


I think you are in a difficult position. I have been in a team where people would not write unit tests, or worse, horrible un-maintainable unit tests. But everybody was aware of the fact that unit testing is good.

So getting the team's unit test suite to be of a good quality was a long an tough road. Always on the lookout of where things could be improved, communicating ideas, sharing experiences.

You on the other hand have a developer that has not even realized the benefit. And then also codes spaghetti code. I guess one of the most important reasons in this particular case is the fact that writing good unit tests forces a loosely coupled design. So getting her to write the test could hopefully in the long run also improve the "real" code.

But I think that in the end, it is a team decision (I don't know how many you are on the team?). If the team can reach a consensus that there should be a well-covering unit test suite, then everybody must conform, share experiences, and let your team grow strong together.

If the team however cannot reach a consensus that you should be writing unit tests, then I suggest that you find a different development team to work with ;)


Is she the boss?

If so... you are kinda stuck unless you can convincer her of the benefits that are basically along the lines of "an ounce of prevention is worth a pound of cure". Bugs get thru. TDD helps mitigate that by building consistent output.

Is she not the boss?

What are the coding standards where you work? Why is she allowed to spew out spaghetti code? Present a business case to the boss saying "We will spend a LOT less time on bugs if we spend a little more time on TDD". Convince someone who can enforce change with a business case.

Document cases where TDD could have saved time & $$MONEY$$.

This bug presented itself. It would have been caught before going live. Spending 2 hours of prevention would have saved us 10 hours of cure. It's happened here and here and here. That 10 hours of work that would have saved the company 30 man hours. That's this much money.

  • 1
    Trying to enforce unit tests from above is like forcing your spouse to eat more vegetables. They will comply reluctantly at best, and fall back into old habits when you stop watching. Better treat developers like responsile adults and convice them that unit tests are useful.
    – nikie
    Commented Feb 3, 2011 at 17:02

This leaves me in the position of modifying something


They created the problem. They should solve it.

What manager is allowing this to happen? Why is someone else's buggy code now your problem?

You have a colleague and a manager that are both making this happen. And by cleaning up their mess, you are a willing and active participant.

Nothing will get changed if they don't feel the pain of poor quality.

  • > They created the problem => They should solve it. Sometimes the people closest to the canvas can't see the whole picture. Writing a unit test would be doing a little bit of work but not necessarily cleaning up others' work. An opportunity to lead by example. Commented Feb 3, 2011 at 13:14
  • 1
    @JBRWilkinson: While true -- and what I often do -- it doesn't effect any cultural change. If someone refuses to do tests, there is a culture in place that makes this refusal (a) possible and (b) reinforced as good behavior. Silently taking on the burden of fixing someone else's mess won't fix the underlying causes.
    – S.Lott
    Commented Feb 3, 2011 at 13:35
  • While I agree that it'd be unsustainable for team members to just churn out crappy code and count on others dealing with their mess, I think it's harmful to adopt a "if you break it, you own it"-mentality. You don't want people to be afraid of changing and improving the code. Instead, focus on spreading good practices and build a sound test suite. Then you can work towards a more "shared ownership" mindset. It's everyone's code. Everyone fixes it, everyone improves it and takes responsibility.
    – sara
    Commented May 16, 2016 at 15:45

She's quite correct, unit tests are "more code".

However it's simply more code that has to be written to ascertain that the program works how it should (over and over again). It is not wasted time. It's as much a part of the system as it's core components.

Challenge her on:

  1. What happens if someone who's not familiar with the code changes something.
  2. What happens if someone who's inexperienced changes something.
  3. The cost of maintaining a system is not measured in how long it takes to create. It's a longer term proposition. Think about the total cost of ownership.
  4. Her estimate (if that was required before coding started) should include the requirement to write unit tests. Business people don't create requirements that require unit tests directly, but they do have an implicit requirement of quality and require that future changes are not riddled with bugs or that the same programmer change its source.
  • I'm not sure I buy "it's more code" just like that. It might be. It probably often is. But it doesn't have to be. A good test suite helps you both in writing less code to begin with (you know when you're done and can stop straight away) and helps you refactor and minify the code more often. This results in a lot of tests and not that much production code, as opposed to no tests and a big messy blob of production code that will never get cleaned up.
    – sara
    Commented May 16, 2016 at 15:48

Speaking as one that currently does production code, followed up by unit tests rather than TDD, which doesn't seem to be a good fit at my current place (I've done TDD on some projects, but see it just as another tool in the ol' bag, not a silver bullet)...

It can be a hard sell. I've still not been able to sell my co-workers on unit testing. I know that I tend to make a lot more errors in my unit testing code than in my production code. So, it's a bit frustrating to have to spend so much time fixing unit test code... However, it's nice insurance when code is modified. Great way to test edge conditions automatically.


Show her how much unit tests help by creating unit tests yourself.

As St. Francis once said, "Preach Always. When necessary, use words."

If she sees that your code is using unit tests, and that you're able to solve bugs more quickly with unit tests, then it may change her mind. But, it may not.

No matter the outcome, she doesn't see you as pushing something on her that you aren't willing to do. That's what you have to change, the perception that you aren't leading by example.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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