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';
[download]

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.