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

[Dallaylaen]

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).