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.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.