Mock Objects

Peter Dimov has published his Master's thesis. To quote him:

It is based on Test Driven Development with Mock Objects, hence the focus is on interaction-based testing. I'm introducing the mocking framework CalitkoMocks, which is specially designed to provide a notation for writing tests that can be mapped one-to-one to sequence diagrams. Sequence diagrams are classically used to specify object-oriented software systems, however, it is obvious that just a bunch of diagrams representing individual cases cannot really be regarded as a specification. To address this point, I'm also presenting a few test refactorings which help to extract test scenarios (i.e. generalized test cases), which are more suitable to use as a specification.

He's implemented a mock framework for C++ that's part of Calitko

I especially liked his closing remark

After I drew the diagram corresponding to my test, I decided to try to write a test corresponding one-to-one to the sequence diagram. The sequence diagram showed the calls to my stub objects but my test didn’t (because the implementation invoked them implicitly). I ended up writing smarter versions of my stubs which eventually evolved into mocks. Though I had already read about mocks at that time, I didn’t quite get it what kind of beasts these were. It was only after I reinvented the mock that I truly understood the concept.

Perhaps this is a step on the way to addressing Jason Gorman's concerns.

Labels: design, mocks in action, news, specification

We have a couple of sessions at XpDay London. Steve will be giving our Synaesthesia talk on Monday. On Tuesday, Nat, with Romily Cocking, Andy Pols, and Steve (part-time) will be giving an introductory tutorial on TDD with Mocks. Book soon!

Labels: jmock, news

Yesterday I visited a team at a Cyrus Innovation site. They came up with this example. If you can't read it, the writing on the ball says "Throwable". Cute.

Labels: mocks in action, pictures

On a side note, this blog is "powered by Blogger" and I keep getting bits of the UI text in German. Does anyone have any idea what's happening?

Labels: by the way

Brian Marick has posted an interesting proposal for changing the order of the pieces within a unit test. For example, he suggests moving from

def test_checker_normally_checks_network_once 
  checker = testable_checker # creates checker using mocks.
  @network.should_receive(:ok?).once.with(”url”).and_return(true) 
  checker.check(”url”) 
end

to

def test_checker_normally_checks_network_once 
  checker = testable_checker 
  during { 
    checker.check(”url”) 
  }.behold! { 
    @network.should_receive(:ok?).once. 
             with(”url”).and_return(true) 
  } 
end

which shows what you can do if you have a language with useful constructs.

Personally, I've tended to think of stubs and expectations in terms of pre-conditions and post-conditions, so I find the pre-test setup less disturbing—and I've been doing it so long I don't see it any more. I imagine it's rather like getting used to (+ 1 2), which Brian ought to recognise. If I were to have a go, I think I might try to write some like this:

during {
  checker.check("url")
}.expect_to_see {
  @network.ok?("url") { returning true }
  @timesink.sleep_for(32.minutes) { 6.times }
  but_not @listener.inform
}

It's nice to see someone experimenting with the ideas.

Labels: design, domain-specific-language