good chemistry is complicated,
and a little bit messy -LW
Re: Mock Objectsby mstone (Deacon)
|on Apr 11, 2002 at 21:40 UTC||Need Help??|
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:
which makes the error in the following code stanza:
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:
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:
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. ;-)