Re: RFC: Perl Testing -- How to Introduce to a team

I think that the most important testing module that I learned was Test::Class. It is basically providing a OO structure to writing your tests. A good example of this is writing data Models that are working with a datbase.

I use the built-in setup and teardown methods to declare each set of tests as a transaction. When I do this I don't have to worry about which tests were run first. All db changes done for a test are automatically rolled back when they done.

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 adrianh (Chancellor) on Oct 20, 2006 at 18:27 UTC
I think that the most important testing module that I learned was Test::Class. It is basically providing a OO structure to writing your tests. While I am (unsurprisingly) quite fond of Test::Class, I'm not sure I'd recommend it as a first step if you've not done testing in Perl before. Especially if you're not particularly familiar with OO. Start with Test::More and friends then, if you start finding you're wanting to factor out common testing functionality, take a look at Test::Class.	[reply]
Re^3: RFC: Perl Testing -- How to Introduce to a team by Herkum (Parson) on Oct 20, 2006 at 19:12 UTC
It does have a higher learning curve than just using Test::More. The problem with avoiding an OO oriented approach is that they will quickly run into issues once their testing needs become significantly detailed. Better that they tackle good practices right off the bat and avoid reenforcing procedural programming that they are used too.	[reply]
Re^4: RFC: Perl Testing -- How to Introduce to a team by adrianh (Chancellor) on Oct 20, 2006 at 19:53 UTC
The problem with avoiding an OO oriented approach is that they will quickly run into issues once their testing needs become significantly detailed. Well - I tried very hard to make it easy to refactor from Test::More based test scripts to Test::Class based modules - so I'll be kinda sad if this turns out to be a problem to move to Test::Class once they hit the issues. Better that they tackle good practices right off the bat and avoid reenforcing procedural programming that they are used too. I certainly don't think Test::Class is a best practice. It's a way of testing, better suited to certain kinds of environment. I certainly don't use it for everything that I write. Adding complexity when it's not needed seems like a bad thing to me.	[reply]