Hack #62. Segregate Developer and User Tests

Run only the tests you need when you need them.

In general, the more tests you have for a system the better. In specific, the more tests you have, the more time it takes to test your code. In very specific, some tests are more valuable than others. You may reach 95% confidence by running a few test files (user tests) and that may be good enough for day-to-day operations. You may also have a few deeper tests (developer tests) that use external resources or take a long time to explore all of the potential possibilities for failure—and you don't necessarily want to make everyone run them all at once.

If your project uses Perl's standard module-building tools (at least, Module::Build, which comes very highly recommended), you can segregate developer and user tests very easily, running the time-consuming tests only when you need to, perhaps right before a release.

The Hack

To customize Module::Build's behavior, almost all you have to know is to define your own subclass and override the appropriate ACTION_* method. How about running only the user tests with the normal perl ./Build test invocation and all tests with perl ./Build disttest?

It's helpful to skim the source of Module::Build::Base [Hack #2] when overriding an action. That's where you can learn that the next method to override is find_test_files( ). The ACTION_test( ) method calls this to figure out which tests to run. Override the test finder method to filter out developer ...

Get Perl Hacks now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.