http://www.perlmonks.org?node_id=180223


in reply to Re: So I'm in a bit of a quandary
in thread So I'm in a bit of a quandary

I seem to be "Pedantic About Good Programming Practices Man" this morning, yet another super(?)hero that nobody really wants to see:

Don't forget the regression tests. There's little more embarassing than refactoring a program "to improve its robustness", then breaking the code in various subtle ways that slip into production. Properly written regression tests let you say to your manager: "So it works the way it did before, and also does foo, and I can add new features in half the time" with some actual data to back you up.

See also How You (Yes You!) Can Get Involved and The Joy of Test, among others.

--
The hell with paco, vote for Erudil!
:wq

Replies are listed 'Best First'.
Re: Re(2): So I'm in a bit of a quandary
by John M. Dlugosz (Monsignor) on Jul 08, 2002 at 18:33 UTC
    I'm big on unit testing. The unit test becomes the regression test after a change is made. If someone reports a problem and it gets down to a small code sample, I add that to the unit test before fixing it.

    Somehow I doubt that his existing code has unit test code with it. So just what is it supposed to do? Mudding the difference between what it's defined to do vs what it just happens to do is one of my pet issues, too.

        Somehow I doubt that his existing code has unit test code with it. So just what is it supposed to do? Mudding the difference between what it's defined to do vs what it just happens to do is one of my pet issues, too.

      In this case, I'd probably try to test against what the old code actually does, especially if it's been in production for a while (with people depending on its quirks). Exercise each feature of the old code (and any combinations that seem to be interdependent), capture the output, and diff. (Not nearly as easily done as said, I know. :-( )

      --
      The hell with paco, vote for Erudil!
      :wq