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.