Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^4: Does anybody write tests first?

by kyle (Abbot)
on Feb 22, 2008 at 14:08 UTC ( #669563=note: print w/ replies, xml ) Need Help??


in reply to Re^3: Does anybody write tests first?
in thread Does anybody write tests first?

Testing that perl can load a module and converting the result into a 0.05% change in a statistic is stupid.

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.

One might have modules that are rarely used, or loaded dynamically via require. If your other testing isn't very good, at least you can check these rare cases with a quick Test::More::use_ok.

If someone broke a module such that it doesn't load, I want to show that before I get ten minutes into another (manual) test that depends on it.

Certainly there are ways to misuse a simple "does this load" test, but they are not without value.


Comment on Re^4: Does anybody write tests first?
Select or Download Code
Re^5: Does anybody write tests first?
by BrowserUk (Pope) on Feb 22, 2008 at 18:18 UTC
    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.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      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.

        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)?

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://669563]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (7)
As of 2014-08-21 02:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (127 votes), past polls