Very nice work! This is in Meditations, so I hope you don't mind some questions/feedback...

my $foo = My::Module->bloated_untestable_method;
[download]

I've definitely run into that, and although sometimes it isn't feasible (read: legacy code), bloated_untestable_method() should be re-written into underlying functionality-based subs that can be tested. I digress for the purposes of your work here.

refute_these {
    like $foo->{bar}, qr/f?o?r?m?a?t/;
    can_ok $foo->{baz}, qw(do_this do_that frobnicate);
    is_between $foo->{price}, 10, 1000, "Price is reasonable";
};
[download]

Now, I see you peeking into the innards of the object here, so it screams loudly that things should be further broken up with accessors that can be tested. This is kind of related to the above statement, and for similar reasons. Tests/assertions like this scream to me that further work needs to be done on the particulars of the object innards:

sub bar {
    return $_[0]->{bar};
}
sub baz {
    return $_[0]->{baz};
}

# or even, if attributes are related:

sub get {
    my ($self, $want) = @_;
    return $self->{$want};
}
[download]

Personally, I am one who really, *really* tries to stay as close to core as possible, unless there's a significant reason for not doing so (eg. a really good existing wheel, perhaps the one you wrote here), so I'm wondering if this distribution is meant for new code, or for aiding the writing of a test regimen for legacy/existing code.

I'll even go one step further to be a pain in your ass ;) Can you please lay out examples of the following statements for my, and future readers' purposes?

• Testing the method requires many preconditions/dependencies;
• The method includes side effects and outside world interactions that are not easily replaced with mocks;
• The method only misbehaves sporadically, doing what it should do most of the time, and the exact conditions required are not known;
• The method needs to be refactored to be properly tested, and needs test coverage to be refactored.

I promise I am not trying to be a smartass or cause you issues. I have App::RPi::EnvUI that has so many moving parts, I *do* have code within the modules that mock, test and otherwise have to perform ridiculous procedures when it understands it is in either prod mode or test mode, so I'm looking for something to make my life simpler, and would largely appreciate a more thorough understanding of how I can use your distribution (ie. here's a good example of how you can sell it).

Again, great work. Your documentation appears clean and concise (although I haven't tested it so I can't confirm its efficacy), and the code (after a very quick glance) looks nice and clean, and with comments sparsely populated where it makes sense.

Do you have a real world example to display which made you decide to write this distribution?

-stevieb

---

---

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.