Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Re^3: Testing at the right granularity

by grinder (Bishop)
on Apr 20, 2005 at 06:31 UTC ( #449496=note: print w/replies, xml ) Need Help??

in reply to Re^2: Testing at the right granularity
in thread Testing at the right granularity

a single "logical" test can result in a bunch of "atomic" tests

I agree with the other replies to this, but just to play devil's advocate...

There can be a value in doing the things the second way, but it depends on factors that only you can judge. It comes down to a question of information gathering.

If having a multitude of tests means you are able to pinpoint the exact point of failure in your code ("Hmm, the eighth character is uppercase, I guess that means someone optmi^broke the the tau_gamma() routine again") then the tests are worth doing.

If only one of the atomic tests fail and the information is useful (helps you zoom in faster to the problem area), then do it that way.

What you will usually find though, is that if the "logical" test fails, you will have a cascade of failing "atomic" tests as well, all pointing to the same problem. Here, no new information is being added to the picture. If this is the case then just do the logical test and be done with it.

Remember to test for the boundary conditions. In Perl, I find this often means dealing with empty arrays (), references to empty arrays and lists ([] and {}, respectively), empty strings, undef and the values '0' and '0 but true' or 0e0.

- another intruder with the mooring in the heart of the Perl

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://449496]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (4)
As of 2020-11-28 20:41 GMT
Find Nodes?
    Voting Booth?

    No recent polls found