Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

How do folks organize unit tests?

by hesco (Deacon)
on Mar 04, 2006 at 04:38 UTC ( #534420=perlquestion: print w/ replies, xml ) Need Help??
hesco has asked for the wisdom of the Perl Monks concerning the following question:

OK. I just tried out Modules::Starter for the first time. I was interested in seeing what sort of testing framework it created.

If I created a new Module with Foo::Bar,Foo::Baz,Foo::Fab, and Modules::Starter built the following t/ directory (with 00-load.t, boilerplate.t, pod-coverage.t and pod.t), where is it I should start building unit tests for Bar, Baz and Fab? How do the pros organize this? Surely there is some convention to it?

-- Hugh

Comment on How do folks organize unit tests?
Re: How do folks organize unit tests?
by lachoy (Parson) on Mar 04, 2006 at 04:50 UTC

    The easiest thing to do is look at a few modules on CPAN and see how they do it. Typically you'll find lots of *.t files in the t/ directory, sometimes they'll be prefixed with numbers so they'll execute in a predictable order. (Whether that's a good idea is a different post.) But whatever you do try and make the test names as descriptive as you can.

    Chris
    M-x auto-bs-mode

Re: How do folks organize unit tests?
by chromatic (Archbishop) on Mar 04, 2006 at 07:49 UTC

    Assuming each module is reasonably separate and reasonably small, I usually start by creating one test file for each module.

    If the distribution as a whole represents a reasonably complete application, I try to include customer-level tests as well that exercise the main user-visible features on their own... but that's a different story from what you're asking.

Re: How do folks organize unit tests?
by xdg (Monsignor) on Mar 04, 2006 at 15:15 UTC

    As chromatic says, if I'm testing a single, small module, I usually just use a single .t file. I would rename 00-load.t to 00-Foo_Bar.t and put all my tests in it.

    If it's multi-module or just complex, I break up the test files by related functionality. Since I tend to favor test-driven development, I find that I create a new test file for each new feature I implement. As soon as I'm "done" with a feature and on to the next, I create a new test file.

    Breaking it up like this means that I'm usually only running the tests for the current feature under development, which keeps the testing time down. Then periodically, I run the full test suite to make sure I didn't break anything else in the process.

    Often, I find that some tests wind up being a loop over a bunch of test data in a datastructure. (See Re^2: Wanted, more simple tutorials on testing for an example of this.) I that case, I usually make a separate .t file for each datastructure.

    As a side note, if I'm thinking of distributing this to CPAN, I also make the boilerplate pod.t and pod-coverage.t optional by adding something like this at the top:

    use Test::More; plan skip_all => "Skipping author tests" if not $ENV{AUTHOR_TESTING};

    Not everyone agrees with this approach, but that's how I do 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.

Re: How do folks organize unit tests?
by dragonchild (Archbishop) on Mar 04, 2006 at 15:32 UTC
    Have each .t file exercise a specific part of your functionality. It's ok to have a lot of test files if your distro has a lot of use cases. For example, DBM::Deep is up to 29 test files and I'll be adding probably 3-4 more in the next month.

    It's also ok to have only 2-3 testcases in a .t file. Remember - each .t file is run in a separate process, meaning that each one is in its own sandbox. There's a lot of safety in that - don't feel obligated to condense the number of .t files you have.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://534420]
Approved by kvale
Front-paged by Tanktalus
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (9)
As of 2014-12-23 01:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (133 votes), past polls