Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

The Evil Pleasures of Unit Tests

by dws (Chancellor)
on Aug 30, 2003 at 09:12 UTC ( #287889=perlmeditation: print w/ replies, xml ) Need Help??

Once you've finally gotten it into your teammates' heads that checking in code that breaks the build is a Very Bad Thing, you can break the build yourself, and not get blamed for it. How? Very simply. When you discover that one of your teammates has checked in flakey code, add a test case that demonstrates a failure, and check in the test case. Boom, there goes the build. But is is your fault? Heh heh, no.

I'm really loving this aspect of unit testing right now.

(Cue maniacal laughter)

Comment on The Evil Pleasures of Unit Tests
Re: The Evil Pleasures of Unit Tests
by tachyon (Chancellor) on Aug 30, 2003 at 09:21 UTC

    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.
Re: The Evil Pleasures of Unit Tests
by adrianh (Chancellor) on Aug 30, 2003 at 09:22 UTC

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

Re: The Evil Pleasures of Unit Tests
by zakzebrowski (Curate) on Aug 31, 2003 at 20:03 UTC
    You're making the assumption though that the other programmer's want the build to succeed. (Insert Political Holy Wars here...)


    ----
    Zak
Re: The Evil Pleasures of Unit Tests
by Steve_p (Priest) on Sep 03, 2003 at 16:50 UTC

    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://287889]
Approved by BazB
Front-paged by grinder
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (8)
As of 2014-12-17 20:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (33 votes), past polls