Naming a block function to check a group of runtime assertions

Dallaylaen has asked for the wisdom of the Perl Monks concerning the following question:

Hello dear esteemed monks,

Let's say I have a block function that checks several conditions and fails loudly if any of those are not met ("loudly" means carp/croak/some callback depending on per-caller settings). The names of conditions themselves follow the conventions of Test::More. This is done so to allow for moving them to a test script after good enough testing environment is available.

So the usage is as follows:

use Runtime::Test::Module;
use My::Module;

my $foo = My::Module->bloated_untestable_method;

complain_if_the_following_does_not_hold {
    like $foo->{bar}, qr/f?o?r?m?a?t/;
    can_ok $foo->{baz}, qw(do_this do_that frobnicate);
};
[download]

My question is: how should such a function be named?

The module already has refute for checking a single condition (stressing the fact that we only can disprove things by testing). It also has a contract block function to save a set of conditions for later execution.

What I could come up with so far:

carp_refute - but it doesn't necessarily carp!
runtime_check - there are many other runtime checks
refute_these - hello Benchmark, but maybe it's good
runtime_contract - way too long, but maybe it's good

Also if there is a CPAN module for blocks of multiple runtime assertions I would love to see a link. What I've seen so far is either Test::* stuff, one-at-a-time assertions, or full-blown design by contract frameworks. But maybe I just got my keywords wrong...

Comment on Naming a block function to check a group of runtime assertions Download Code

Replies are listed 'Best First'.
Re: Naming a block function to check a group of runtime assertions by 1nickt (Canon) on Dec 24, 2017 at 23:43 UTC
Hi, to allow for moving them to a test script after good enough testing environment is available. What does this mean? I don't see anything in the code you showed that cannot be in a normal test file run under the test harness. Can you expand on this? use Test::Most; use_ok('My::Module'); # via FindBin, `use lib`, if needed subtest 'bloated_untestable_method' => sub { ok( my $foo = My::Module->bloated_untestable_method, 'instantiate' + ); like( $foo->{bar}, qr/f?o?r?m?a?t/, 'value of `bar`' ); subtest 'baz' => sub { can_ok( $foo->{baz}, $_, "`baz` can `$_`" ) for qw(do_this do_ +that frobnicate); }; }; [download] The way forward always starts with a minimal test.	[reply] [d/l]
Re^2: Naming a block function to check a group of runtime assertions by Dallaylaen (Chaplain) on Dec 25, 2017 at 09:07 UTC
Hello 1nickt, I tried to produce as short a summary as I could. The following concerns may be the case with a real b.u.m. (`bloated_untestable_method`), though: b.u.m. has many dependencies - need to construct a lot of objects to make a meaningful call; b.u.m. has side effects - which means mocks must be built to account for them; b.u.m. interacts with the outside world, like querying a web-service - need to build a mock for that b.u.m. only misbehaves sporadically, producing normal output most of the time. And we don't know the exact conditions under which it happens. Of course these are all bad signs. B.u.m. needs to be split into smaller functions with narrower responsibilities. But that in turn requires getting at least some test coverage on it. And covering it with tests would require prohibitively much time. My idea is that runtime assertions can serve as a safety net when fiddling with b.u.m - at least they can provide some warning before angry customers arrive at the office. Also they may catch an unintended effect of changing one of b.u.m's dependencies (aka spooky action at a distance). This is all unneeded in case of proper design but properly designed modules are somehow more common on CPAN than in production (at least in my experience).	[reply]