in reply to Checking parameters passed to a third party module during testing

If I understand the description correctly, your code looks like this:

sub ... { # stuff to parse the email my %params = ... my $msg = MIME::Lite->new (%params); my $result = eval {$msg->send}; }
and you want to check %params from the test file.

If that is the case, you could add a validation routine for %params and call it before you create the MIME::Lite object. Then the test file could test the validation routine.

I'm not completely sure what you mean when you say "check the contents of %params is as I expect without from the test code without instrumenting my module under test", though, so this may not be an option. Also, I assume when you said %params is local to the sub you meant it was lexically scoped to the sub, not declared with local.

Replies are listed 'Best First'.
Re^2: Checking parameters passed to a third party module during testing
by GrandFather (Saint) on Oct 18, 2006 at 06:08 UTC

    That is in essence correct. In fact params is a compilation of parameters from various places. There is already validation code to check that the correct parameters are present. What I need the test system to do is ensure that the parameters have the correct values given known email text. That is, I want to check that the parsing process is generating the correct output email for a given input email.

    What I think I need in the test script would look something like:

    my $emailBody = '...'; my %generatedParams; # possibly some magic here to associate %generatedParams with %params +contents ok (parseEmail ($emailBody), 'Email parsed without error'); # possibly some magic here to get %params contents into %generatedPara +ms ok ($generatedParams{to} eq 'to@addr', 'To address generated correctly +'); ...

    Yes, I mean %params is lexically scoped to the sub. (That's the C++ shining through.)

    Update: Perhaps I should add that the sub containing the send code is not where the parsing is done,but it is the only place where all the pieces that comprise the email content come together. Various header information such as subject, to and from addresses and possibly other information headers are generated in the sub.


    DWIM is Perl's answer to Gödel