Re^5: Does anybody write tests first?

[BrowserUk]

A simple sanity check before deployment might simply check that everything loads correctly. As you know, use does more than just load. It actually executes code, in some cases. If the environment has changed, the config has changed (as it often does when you go to production), just loading a module might break.

But don't you see that all use_ok does, is allow the test script to continue when the use has failed. It doesn't test anything extra. It doesn't tell you any more. It doesn't verify exports, or configuration, or tell what piece of code failed. Indeed, if any warnings or errors are produced that might tell you what failed and why, it hides them from you.

And, unless you are testing more than one module from that test script (which I assume no one does), there is nothing else useful to do, because if the use failed, none of the other tests are viable. Literally all you've done by using use_ok is allow the running of further tests that cannot possible succeed. Oh. And allowing the harness to count more imaginary numbers.

[kyle]

unless you are testing more than one module from that test script (which I assume no one does)

Sorry this was unclear. When I wrote of a "simple sanity check before deployment", I actually did mean a test script that does nothing but use_ok over and over with no other tests.

When I've had a project with numerous modules, I have found it useful to have use_ok tests for all of them in one place.

my @modules = get_module_list();
plan 'tests' => scalar @modules;
foreach my $module ( @modules ) {
    use_ok( $module );
}

If get_module_list() is bright enough to use File::Find, it will pick up modules without me having to explicitly list them. I get a sanity check on even those modules for which I haven't written more extensive tests. As I said, if your other testing isn't very good, checking that use works is a start.

[BrowserUk]

For the reasons given in {net information loss), I see no advantage to your script over:

my @modules = get_module_list();
foreach my $module ( @modules ) {
    require $module;
}

Except that you might discover more than one missing/corrupted module. But, and a very significant one IMO, is that you sould lose the information that told you why the (first) module failed to load. Eg.

• Module missing:

  Can't locate Non/Existant.pm in @INC (@INC contains: C:/Perl/lib C:/Pe
  +rl/site/lib .) at
  BEGIN failed--compilation aborted at -e line 1.
  

• Compilation error:

  syntax error at Existant.pm line 2, near ") {"
  Compilation failed in require at -e line 1.
  BEGIN failed--compilation aborted at -e line 1.
  

• Other(s)?