in reply to RFC: Perl Testing -- How to Introduce to a team

The single best thing I learned about testing from Schwern is to make sure that every time someone finds a bug, they write a test to show the bug before they fix it. This works at the beginning of a project if, as you add feature requests to your list, you write tests for them as you write the code to implement them.

Hence, don't get bogged down in thinking about every possible thing you could test, just get started writing some tests and write more for every missing feature or bug.

Phil

  • Comment on Re: RFC: Perl Testing -- How to Introduce to a team

Replies are listed 'Best First'.
Re^2: RFC: Perl Testing -- How to Introduce to a team
by NovMonk (Chaplain) on Oct 19, 2006 at 13:40 UTC
    I've been wondering about that--in such a case, do you write a test For the bug (passes if it hits) or For the Solution to the bug? I'm thinking the former, and then just Reverse it when it's fixed (passes when the fixed code runs right.)

    Thanks for the comment.
    NovMonk
[reply]
      I write the test so it fails when the bug exists and keeps failing until I fix it. If you don't want it to show up for some period of time, mark it TODO.

      Phil

[reply]

        I want to second this. It's very important to write a test that can replicate the bug before fixing it.

        -xdg

        Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]

In Section Meditations