Re: Naming a block function to check a group of runtime assertions

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.

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

Re^2: Naming a block function to check a group of runtime assertions
by Dallaylaen (Chaplain) on Dec 25, 2017 at 09:07 UTC

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]