Of course the patch you checked in just after proving the failure with the new test case (and checking that in) should make your joy short lived.....You did say teammates right? Of course this make the rash presumption that you are all on the same side ;-)

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

You did say teammates right?

Right. And I don't expect to have to do this for more than another week.

If you're on a project where people are checking in stuff that doesn't work, or only, uh, partially works, there are a couple of ways to handle it. You could quietly fix stuff yourself, but then they won't learn (and they'd probably get pissed at you for reaching into their code). Or you can mark up a listing and hand it to them. Or you can say, without pointing out any specific fault, "I don't care how you implement this, but we've agreed on the interface, and I'm going to hold you to that agreement." A unit test does the latter, and shifts the pain, if any, where it belongs. And if others on the team need to do this to me, then I deserve it.

Standing up for your agreements early in a project can save you a lot of work later on.

I appreciate the value of unit tests too, and not just as an implement of torture for the un-righteous {maniacal laugh} <:-) Actually I posted one of our widgets Autogenerate Test Scripts a while back. This makes it hard(er) to find excuses as to why the test suite is not complete.....but still I hear all sorts of great excuses reasons justifications misc BS. Actually thinking about that I should probably post a couple of others (check.pl which looks to see if the test suites are complete and run which does the obvious).

It never ceases to amaze me how a seemingly trivial change in the behaviour of a given function can cause so many unexpected side effects. Good tests save much pain and embarassment.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Why not find the 'guilty' party, pair with 'em, write the new failing test and then work with them to write the fix? That way you let them know you know that there's a problem, but you're also taking the pressure off them by solving the problem together.

Ah... but just wait until you have something like Test::FIT and your customers start doing it to you :-)

I, for one, see nothing wrong or evil about this. I believe that I remember reading something similar to this on Joel On Software. His take was that you should bury poor programmers on your team with bug reports. The result is that they will either improve or leave.

Also, regarding some of the other comments above, just because someone is on your team doesn't mean they should not be held responsible for the problems they cause. Adding additional tests is somewhat of a backdoor way of making them responsible, but, if all else fails, I'd think it is a very appropriate way to get someone's attention to their poor code.