Are there conventions for function names when using the Perl Test::More?

Question

Are there conventions for function names when using the Perl Test::More or Test::Simple modules?

I'm specifically asking about the names of functions that are used to set up a test environment before the test and to tear down the environment after successful completion of the test(s).

cheers,

Rob

Answer 1

I do not think there is a official set of conventions, so I would recommend looking at the examples at http://perldoc.perl.org/Test/More.html and see how the write their tests.

Answer 2

Thanks Espo.

I've had a look at the relevant perldocs but there's no real convention regarding the setup and teardown aspects.

Not like XUnit series of tests.

Thanks for the answer Jagmal but I'm not sure about using the BEGIN and END blocks for the setup and teardown as you are not making clear what you are doing by the names. There's also the obvious problem of only having one setup run and one teardown run per test, i.e. per each .t file.

I've had a quick look at Test::Most and it looks really interesting, especially the explain function. Thanks Matt.

Hmmm. Just thinking further about using the BEGIN and END blocks, I'm thinking if I decrease the granularity of the tests so that there is only one setup and one teardown needed then this would be a good solution.

cheers,

Rob

Answer 3

I dont think there are any such conventions out there.

The only way you can do it is perhaps use BEGIN/END blocks, if the resources are to be used over the whole file.

The general approach I take is to put related tests in one code block and then initialize the variables/resource etc there. You can perhaps keep an easy count of how many tests you have for each function.

Something like ...

BEGIN {
   # If you want to set some global db setting/file setting/INC changes etc
}

# Tests functionality 1...
{
     # have fun .... 
}

# Tests functionality 2...
{
     # have more fun .... 
}

END {
   # Clean up the BEGIN changes
}

On other note, you may want to read this for testing in perl ... http://perlandmac.blogspot.com/2007/08/using-perl-testsimple-and-testmore.html

Answer 4

We use Test::More extensively for our unit tests as a lot (most) of our data processing scripts are written in Perl. We don't have a specific convention for the function names but rather do something like Jagmal suggests, namely breaking the tests up into smaller chunks and initializing locally.

In our case each subtest is encapsulated in a separate function within the test script. On top of this we have a framework that allows us to run all the subtests (the full unit test) or call individual subtests or sets of subtests to allow for running of just the ones we're working on at the moment.

Answer 5

First convention I'd suggest is ditching Test::More for Test::Most

Answer 6

Perl testing scripts aren't special or magic in any way. As such, they can contain the exact same things that any other Perl script can.

You can name routines anything you want, and call them before, after, and intertwingled with, your tests.

You can have any amount of initialization code before any tests, any amount of cleanup code after tests, and any amount of any other code mixed in with tests.

This all assumes that you're talking about CPAN-style t/*.t test scripts. I think you are, but I can manage to read your question as one about extending test harnesses, if I squint just right.

Answer 7

If you are looking for more XUnit-style testing, check out Test::Class. It provides the Test(setup) and Test(teardown) attributes for methods that, well, set up and tear down your environment. It also gives you a much nicer way of dealing with plans (you can provide one for each test method individually, so the counting is much less fiddly) and lets you inherit tests via test class hierarchies.

Answer 8

If you are open to get into acceptance testing as well, like Ruby's Cucumber - take a look at this small example http://github.com/kesor/p5-cucumber that is using Test::More and a cucumber style of acceptance testing.