3

On our Scrum team there are a couple of members who crank stuff out to the page without unit testing, then complain when changes are made elsewhere in the code that break their stuff. The refrain is always "It used to work, what did you do?"

We are early in moving to Agile, and CI is one of the next things on the agenda. Until then, how do I deal with the people problem? That's the part that is hardest to deal with, after all.

skaffman
  • 398,947
  • 96
  • 818
  • 769
KevDog
  • 5,763
  • 9
  • 42
  • 73
  • dupe http://stackoverflow.com/questions/7252/how-to-make-junior-programmers-write-tests – Epaga Apr 03 '09 at 14:35
  • 2
    People are a little too aggressive in closing things, methinks. I searched before I wrote and didn't find this one, nor did it show up in the hints when asking the question. Where's the harm in dupes anyway? Minds and methods may have changed since last asked and no one scrolls to the end anyway. – KevDog Apr 03 '09 at 15:23
  • 1
    This question isn't dupe anyhow - it's an entirely different matter to convince a junior program to test that to handle an entrenched practice as described here. – Eamon Nerbonne Sep 12 '09 at 09:34
  • See http://stackoverflow.com/questions/7252/how-to-make-junior-programmers-write-tests – Epaga Apr 03 '09 at 14:34
  • Possible duplicate of http://stackoverflow.com/questions/139228/what-do-you-do-with-a-developer-who-does-not-test-his-code – Raedwald Nov 13 '13 at 20:24

7 Answers7

2

You are the team so you have to agree before you get down to work. Without agreement blame game will go on forever (and it is true just about anything).

See my answer to the question about the value of unit testing: The Value of Unit Testing

Community
  • 1
  • 1
topchef
  • 19,091
  • 9
  • 63
  • 102
2

I think the best way to deal with this kind of stuff is through accountability. If their stuff breaks, they take the heat and have to find the fix, even if the root cause is somewhere else, their portion of the problem is that they didn't catch it prior to release.

Note that this may not actually convince them to change their habits though...

Jeff Kotula
  • 2,114
  • 12
  • 16
2

Talk to them. Ask why they don't do unit tests. If it's just laziness, explain how it's a time-saver in the long run (with the specific examples you mentioned), and that yes, it takes some effort to get into, but soon becomes a habit with proven benefits.

If that doesn't help, give them a separate time buget for unit tests and implementation and tell them that it's now their job to spend 5 hours writing unit tests for this use case that produce decent coverage, and that you'll be happy to help them get started.

If that still does not help, fire them and get someone who won't disregard outright orders to do his job properly.

Michael Borgwardt
  • 342,105
  • 78
  • 482
  • 720
1

Playing devil's advocate here, but why are changes elsewhere breaking their code? Would unit tests actually prevent this breakage? Are people breaking or changing interfaces between code units?

I mean, yes, unit tests and design-by-contract are great things, but the code has to have a contract to adhere to. Getting these programmers to write unit tests will help determine when you have a problem, but does it get you closer to preventing those problems? It sounds like there may be a larger design issue that needs to be addressed.

veefu
  • 2,820
  • 1
  • 19
  • 29
1

Whoever breaks the build without writing unit test needs to buy a luch for the whole team.

J.W.
  • 17,991
  • 7
  • 43
  • 76
0

I'd start by looking at your team policies. Why are they allowed to submit code without unit tests in the first place? If you want consistent unit tests then you need to set the policy. You can explain that unit tests are an important way catch regression issues. If they continue to complain, point to the policy and tell them unit tests are not optional.

Aaron Saarela
  • 3,956
  • 1
  • 19
  • 17
0

Use a continuous integration system with a good blame mechanism. Something like Hudson that can continuously check Subversion or other source control systems. Set up your CI build system to send an email as soon as a system test fails that broadcasts the name and change that introduced the error.

In other words, make sure that everyone knows who is introducing the bug and identify the bugs as soon as they are introduced. Over time, these cantankerous developers are going to realize that they are the ones introducing defects.

Tim O'Brien
  • 9,623
  • 5
  • 30
  • 36