Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Gracefully Downgrading Behavior

by Ovid (Cardinal)
on May 10, 2007 at 08:59 UTC ( #614574=perlmeditation: print w/replies, xml ) Need Help??

If you've distributed a module for others to use, you might find that you want to use Test::Differences in your tests, but users might not want yet another module to install. You might want the verbose output of Test::Differences because it makes tracking down problems much easier, but hey, getting a less verbose test report is better than none at all (hell, consider yourself lucky if you get any test reports).

I want to upgrade Class::Trait soon and make the use of Test::Differences optional with code similar to the following:

#!/usr/bin/perl use strict; use warnings; use Test::More tests => 2; BEGIN { eval "use Test::Differences"; if ($@) { *eq_or_diff = \&is_deeply; } } eq_or_diff [ 3, 2 ], [ 3, 2 ], 'first test'; eq_or_diff [ 3, 2 ], [ 3, 2, 1 ], 'second test';

If they have Test::Differences, great. If they don't, they fall back to the Test::More::is_deeply behavior. Not as useful for diagnostics, but better than nothing.

This is something I'm thinking about more and more because while I don't see why users should object to another test module being installed, the reality is, the fewer dependencies we require, the more likely our modules are to be used. I might even use a trick like making a custom test module to make this easier to manage (such as having an optional Test::NoWarnings) and other things.

I recommend all programmers looking at distributing code for general use figure out ways that can gracefully downgrade functionality (if appropriate) rather than force people to install stuff which they may not want or which might itself be difficult to install. POD tests, for example, are excellent candidates for skipping entirely on an end user's machine.


New address of my CGI Course.

Replies are listed 'Best First'.
Re: Gracefully Downgrading Behavior
by gaal (Parson) on May 10, 2007 at 09:15 UTC
    (Here be plugs.)

    When there are several providers of the functionality that have compatible APIs, you can use Best. With modules that just export functions, you simply replace the use line:

    use YAML; # This module is slow! # So if you want to try a faster one first: use Best qw(YAML::Syck YAML); print Dump({ some => 'hash' }); # Dumping provided by Best Possible YA +ML module

    There's knobs you can use to rewire stuff as in your is_deeply example; and a which function is provided so you can get the name of the module that was actually loaded to write factories with.

    use Best qw(OOPishProv AnotherOOPyProv::Serving::As::Fallback); my $obj = Best->which("OOPishProv")->new;

    If you're out for less syntax, you might like to try the possibly too-magical Class::TransparentFactory.

      So you're recommending that I have users install another module so that they don't need to install another module? :)


      New address of my CGI Course.

        Nah :-) This is addressed in the docs. Basically just stick the tiny file in your lib/, or Inline::Module it (maintainer action; the user need not have I::M installed).
Re: Gracefully Downgrading Behavior
by Jenda (Abbot) on May 10, 2007 at 09:40 UTC

    Is there any particular reason why doesn't Test::More itself check for the presence of Test::Differences, use it if available and fall back to its own implementation otherwise? That would look like the best solution to me. And one everyone can benefit from.

      Because Test::Differences requires Test::More.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://614574]
Approved by marto
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (5)
As of 2021-06-13 09:30 GMT
Find Nodes?
    Voting Booth?
    What does the "s" stand for in "perls"? (Whence perls)

    Results (54 votes). Check out past polls.