Hello stevieb,

I welcome feedback, especially the kind that mixes critique and flatter in just right proportion. However, a detailed answer to your inquiry would take some time.

The whole point of this bloated_untestable_method example was showing how Refute can help improving on legacy code (just as you point out). Refute covering your back may become a tipping point where rewriting legacy code turns feasible. In fact, my example could be worse as in:

sub big_one {
    # a lot of code here
    my ($foo, $bar, $quux);
    {
         # Big block of code nobody had courage to move into a subrout
+ine
    };

    refute_these {
        can_ok $foo, qw(so_this frobnicate), "Assigned an object to fo
+o";
        like $bar, qr/f?o?r?m?a?t?/, "bar is in right format";
        is_deeply $quux->{megahash}, $_[0]->{megahash}, "Data round-tr
+ip"; 
    };

    # even more code

}; # sub ends some 500 lines below
[download]

And adding refute_these to the mix serves both as a safety net when fiddling with code at hand and a prototype of the unit test for the upcoming replacement.

This is what I'm actually pushing at my current workplace. There's a gaping hole between the standards we set for new code and the old code's style.

For fresh code, the usage is much more subtle. I can think of several cases, but haven't tried any of those yet:

• Loading a plug-in? Run a behavior test at the spot. Make sure plugin authors are aware of the spec they develop to - you can just copy-and-paste refute block into documentation.
• Run a model round-trip test upon connecting to database. Don't wait until actual requests start failing. Roll back transaction afterwards. Will try this in my Potracheno tech debt tracker shortly.
• Writing a Foo::PP module? Create a spec-in-code so that Foo::XS, Foo::Fast, Foo::Tiny and Class::Foo developers don't have to come up with their own (slightly different) test suites.

Now all of the above looks like design-by-contract. There are some modules for that on CPAN, but it feels like a bit of overkill and a bit of "take it or leave it" for most cases.

Thanks again for your reply, and I hope to come back with some practical suggestions/examples soon.