Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jplindstrom (594)

  (email not shown publicly)

Journal of jplindstrom (594)

Friday July 23, 2004
06:28 AM

State vs Interaction based Testing

[ #20016 ]

Very interesting article by Martin Fowler about the use of Mock Objects in unit testing and how they influence the style of testing.

Mocks Aren't Stubs

The article seems pretty "complete" in that I repeatedly thought about issues that he later covered and discussed, like the coupling to implementation that Interaction based testing brings, the need for integration tests etc.

Personally, I have only ever done State based testing for real and even though I knew of Mock Objects (Piers Cawley did a brief talk at YAPC::Eu Munic a couple of years ago) I've never really used the technique. I thought the biggest point was to provide an environment to the tested object so it could make it through the test without barfing (i.e. using the mocks as stubs), but from Fowler's article it seems providing TDD guidance is at least as important.

The Java mock object classes in the article seems very useful with an elegant interface for defining what the mock object should do and evaluating how it was called. From reading the docs of Test::MockObject it seems to be similarly capable, but with a different interface. It may be more suited to the Test::More way of doing things rather than the xUnit way with test classes.

Googling CPAN for examples didn't match that many documents, but at least there are a few examples of real-world use.

I think I'll give it a test-drive and see how it works out.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Mocks are generally divided up into static vs dynamic. Dynamic mocks can be implemented by something like Test::MockObject [] (or EasyMock in Java) -- generally you create a generic object, tell it what it should do and how it should respond, then put it in your framework.

    Static mock objects have their place too. They're around in Perl, just not as explicitly as in Java. For instance, you have Apache::FakeRequest [] distributed with mod_perl, or the DBD::Mock [] module I wrote to fake a database driver. Creating s

    • Thanks for the link, I found it very informative.

      One small (hopefully constructive) criticism of this slide [].

      A while back I was having problems with a certain session module (not apache::session). During my troubleshooting I looked at the tests. Nowhere in any of the test did the author actually save and restore session data. Yet, the primary task of the module is to save some data... and give it back to you later.

      So, while you certainly shouldn't have to test other people's modules... you should at least
      • I didn't mean to say that you should never test other people's code, just that you should avoid it if possible. Particularly if what you're asking the module to do is its entire purpose -- Apache::Session does nothing else except store and retrieve session data, so I think it's a reasonable assumption that it is doing its job. If it's not you have bigger problems, and you hopefully have better avenues to find these problems than running my unrelated test suite. (IIRC I made this point during the actual pres