Uri Guttman wrote: >>>>>> "SB" == Steve Bertrand <st...@ibctech.ca> writes: > > SB> In all honesty, I think I'm learning more about Perl (and my own > SB> programs) writing the tests than I do when I'm writing the programs > SB> themselves. (Same goes for keeping up with the documentation!). > > coding is coding and the more you do the more you learn.
Yep.
> tests are a
> particular area but they don't necessarily use different coding
> constructs than other projects use.
I know, but what it has done, is allowed/forced me to scrutinize on the
finer details that I've always overlooked (type checking, undef etc).
Even though the constructs are the same, the more I get excited thinking
that each test I write will save me an order of magnitude of time later
when I am done the program, and need to change something. (I'm not a
programmer, so I'm sure the "excited" part will wear off ;)
> SB> Given your comments above, would you say that this is better?
>
> SB> my %typedefs = (
> SB> plan_info => \&plan_info,
> SB> user_info => \&user_info,
> SB> plan => \&plan,
> SB> ...etc...
> SB> );
> SB> ...
>
> just so you know, that is called a dispatch table. it is used to lookup
> a sub based upon a key. it is used in many sorts of projects. i wouldn't
> use the name %typedefs as it doesn't say much about the use of the
> table. note that names should reflect how something is used, not what it
> contains. maybe type2info is a better name. i still don't get the use of
> this so i can't create a proper name for it.
I've pretty well always used names based on content, not on use. Makes
good sense, as the content should be able to describe itself. Point well
taken.
> SB> my @known_types = $vardb->is_type();
>
> SB> my @missing_types;
> SB> my %data;
>
> SB> for my $known_type (@known_types) {
>
> SB> unless (exists $typedefs{$known_type} ) {
>
> again, you don't need exists there. since your dispatch table's values
> are always code refs so they will always be true.
...my thoughts there were to catch a situation where I've added a new
data type globally (within the context of the program), but it is not
being tested within this test file, because a test definition hasn't yet
been added. Will "exists" not catch that?
> SB> push (@missing_types, $known_type);
> SB> next();
> SB> }
>
> SB> %data = &{ $typedefs{$known_type} };
>
> you didn't get my point about redundancy. $typedefs{$known_type} is used
> twice which is once too many. if you refer to a hash value (especially
> deep hashes) more than once, it is usually better to grab it into a
> scalar and use that. it will likely be faster (saves hash lookups), it
> is shorter (removed duplicate code) and is usually less bug prone as you
> one have the expression (which can be complex) in one place.
I get it, I get it! I finally see what you mean by that.
> SB> eval { $sanity->check_type( $known_type, \%data, $error ) } ;
>
> SB> unlike ( $@,
>
> again, what is unlike? i now guess it is from a test module. does it
> take a regex as an arg?
unlike is from Test::More. Both unlike and like take a regex as it's
second parameter. I took a quick look at the docs, and the regex is
forced into qr//, which would explain why my '$_' from the previous post
was interpolated properly.
> SB> '/not a defined datatype/',
>
> that isn't a regex, just a plain string with / chars on the ends. maybe
> the unlike call will convert that but the / will be literal / chars. use
> qr// or maybe the string without /.
Yep, see above.
Thanks Uri,
Steve
smime.p7s
Description: S/MIME Cryptographic Signature
