in reply to Perl Style Guides for Large Projects

Although testing is mentioned briefly in the guides you link to I cannot emphasise enough how essential good test suites are for large projects.

Good unit, functional and acceptance tests will save you from much hassle during the development process.

I'd also recommend that you base them on the existing perl modules (Test::Harness, Test::Builder, Test::More, etc.) rather than rolling your own.

  • Comment on Re: Perl Style Guides for Large Projects

Replies are listed 'Best First'.
Re: Re: Perl Style Guides for Large Projects
by strider corinth (Friar) on Nov 01, 2002 at 15:22 UTC
    Also, in order for your tests to be worth beans, write them before you write the code they test. If tests are written after the code, knowledge of the code's functioning will tend to taint the tests, making them much less useful. When you code your tests in advance, you can be sure they're right.

    Love justice; desire mercy.

      In a perfect world so it would be, however test written after the fact can be invaluable and are better than no tests at all. They come into their own every time you change a single character in your code. It never ceases to amaze me how often seemingly benign changes can have unforseen side effects. It is alway reassuring to be able to make a change, run the tests and KNOW that you have not broken anything by accident.




        Hehe. Fair enough. Today was something of a case in point. =)

        I tend to make things seem black and white when I don't really think they are. Tests written before the fact are the ones I find most useful, and I think it's one of the best programming disciplines to make a habit. When specs change, of course, the tests have to change too. And I agree, it is possible to create tests after the fact which are written to spec and don't take the code into account. They're certainly better than nothing.
        Love justice; desire mercy.