Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Mock Objects

by lachoy (Parson)
on Apr 11, 2002 at 20:38 UTC ( [id://158423]=note: print w/replies, xml ) Need Help??


in reply to Re: The Joy of Test
in thread The Joy of Test

There's another interesting way to do this called mock objects. A brief description: "We propose a technique called Mock Objects in which we replace domain code with dummy implementations that both emulate real functionality and enforce assertions about the behaviour of our code." (From Endo-Testing) It's Java-focused, but since Perl has a great tradition of borrowing interesting tools and ideas from other languages I don't think that is a problem ;-)

Since I tend to approach problems like this from a code generation standpoint, I find this very intriguing. What if we were to create metadata to configure how the different methods in our objects are supposed to work? Then the code that uses these objects can always depend on a consistent environment and we can test the interesting stuff -- processes that use the objects -- with full confidence.

I haven't implemented anything with this idea yet, but it -- along with generating most of my unit testing code -- has been in the back of my mind for a while now. Testing sizable data-backed systems is hard, and any boost will be greatly welcomed.

Chris
M-x auto-bs-mode

Replies are listed 'Best First'.
Re: Mock Objects
by mstone (Deacon) on Apr 11, 2002 at 21:40 UTC
    What if we were to create metadata to configure how the different methods in our objects are supposed to work?

    You've just cracked the thought barrier that leads to formal methods. For each chunk of code, you create a list of assertions that impose constraints on what the code should do. Then you go through and make sure your code actually obeys those assertions. Formal methods take the idea a step farther by writing the assertions in mechanically-readable form, then running them through a postulate-matching engine to do the gruntwork of making sure everything checks.

    As a trivial example, let's use a mock-language that uses types to impose assertions, and nail down a common blunder in C programming:

    pointer: a value that refers to another object non-null-pointer: a pointer whose value is not zero string: a sequence of characters in format F sp: a pointer to a string nnsp: a non-null-pointer to a string boolean: TRUE | FALSE boolean strcmp (nnsp a, nnsp b): takes two non-null string pointers and returns TRUE if the strings are equal
    which makes the error in the following code stanza:
    sp x, y; boolean b; b = strcmp (x,y);
    stand out like a sore thumb. strcmp() demands non-null pointers, but the code above is only giving it regular pointers. The code above meets some, but not all, of strcmp's required assertions, and a formal type engine would point out the error.

    Strongly-typed languages build an assertion-tester into the compiler so programmers can build and verify code in the same way. The hints about memory allocation are useful, too. But that's not the only way to handle assertions.

    Even though Perl doesn't use strong typing, we can build our own testable assertions about what the program should be doing, and weave that right into our error-handling code. So while I think your use of the test module is cool, I'd challenge you to crank the quality up one more notch, and make your test code part of the program itself.

    When you code to the assertions, you find yourself structuring programs so that no given operation can possibly fail. Ususally, you end up with a framework like so:

    create a data structure filled with default values known to conform to the required assertions. collect the input that will instantiate this structure. iterate over the input { if (this input is valid) { put the input into the structure. } else { put a conforming error value into the structure. } } ## at this point, we can assume that the structure conforms ## to the assertions, whether the input was valid or not
    and if you make "this structure will be consumable by any client" one of your assertions, you don't have to branch your code to handle error conditions. Simple example:
    %templates = ( 1 => "template one: data = #DATA#", 2 => "template two: data = #DATA#", 3 => "template three: data = #DATA#", ERR => "bad template reference, but the data = #DATA#", ); %data = ( 1 => "data value 1", 2 => "data value 2", 3 => "data value 3", ERR => "bad data reference" ); for (1..20) { $t = $templates{ int rand(5) } || $templates{'ERR'}; ## assertion: we always get a template that will be usable ## in the substitution below. $d = $data{ int rand(5) } || $data{'ERR'}; ## assertion: we always get a value that will be usable ## in the substitution below. $t =~ s/#DATA#/$d/; print $t, "\n"; }
    The assertions guarantee that the main code always works, even if the inputs are bad. The structure of the default values makes both kinds of failure visible, without having to obscure the main-line code behind a bunch of tests and conditional branching.. and multiple failures like the ones in this example are a bitch to handle with binary if-else branching.

    Guaranteed success: Try it -- it's addicitive. ;-)

      You've just cracked the thought barrier that leads to formal methods. For each chunk of code, you create a list of assertions that impose constraints on what the code should do. Then you go through and make sure your code actually obeys those assertions. Formal methods take the idea a step farther by writing the assertions in mechanically-readable form, then running them through a postulate-matching engine to do the gruntwork of making sure everything checks. ... When you code to the assertions, you find yourself structuring programs so that no given operation can possibly fail. Ususally, you end up with a framework like so: ...

      This is cool. Very cool. I admit that I didn't truly grasp your first paragraph at first read, and am still processing it. BUT, with the tutorial/example you gave, I saw the light! I will definitely try this! Thanks mstone - you have cracked my thought barrier, and I am looking forward to eliminating vast multi-level conditionals!!

      ..Jon

      Update: Thanks again mstone for providing links to (what I'm sure will be) some great resources. And BTW I could not imagine pronouncing 'Z' anything but 'zed'... ; )

        I admit that I didn't truly grasp your first paragraph at first read, and am still processing it.

        *snort*

        You should see the forehead-shaped dents in my wall. ;-)

        Really good ideas -- the ones that change the way you think because they change the way you look at things -- take time to absorb. I just happened to find this particular wall before you did.

        One paper you should definitely read before getting too far into the whole business is: What's Wrong With Formal Programming Methods? (PDF, 15 pages, 56K). It's a nice summary of the history and ideas behind formal methods, but doesn't beat you into the ground with impossible-to-type-on-a-regular-keyboard formalisms like the language Z (pronounced 'zed'). It's also a nice antidote to the full-gonzo 'more correct than thou' attitude some formal methods types can acquire.

      Nice post, mstone. I'm curious as to your thoughts of how all this relates to guard clauses as mentioned by dws. To me they seem very similar, but I sense that perhaps guard clauses dance around the issue of self-enforcement by the program, as opposed to merely hammering your input data into normalized form.

      Matt

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2024-03-28 20:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found