in reply to Re^2: Smallish mock objects
in thread Smallish mock objects

Your last comment is very interesting. I'll have a look to state based testing vs interaction based testing, thanks

coming back to the thread, I've always felt that mock objects shine when you *actually* want to be in control:

  • you want to force failures all over the place
  • when you can record "external contexts" so you have state, and you associate your mock object with this external state. Pre-conditions and post-conditions (can be other processes!) can insure invariants. An example would be when your test suite incorporates snapshots of data in a few small (almost) flat databases (say switching on and off at will your big fat Oracle). Needless to say that collecting the data becomes part of the tests.
    • Actually, "internal testing" is the thing most talked about when the real situation is closer to "external testing", I guess. If we look at Chromatic's and Ian Langworth's "perl testing" the ratio is about 10 to one. Even unitary testing if often a mix, and it seems that a generic way to approach "external testing" mechanics would be very useful (if you have pointers about something actually general enough but still practical, IŽll be grateful).

    Maybe I am a paranoid, but I build my systems (even small prototypes) making them fail all over the place. Thinking early about recovery seems to make them better (not really something rational, more like a gut feeling ;)...probably because this over-emphasizes data sources.

    hth --stephan

    Replies are listed 'Best First'.
    Re^4: Smallish mock objects
    by sgt (Deacon) on Dec 20, 2006 at 11:33 UTC

      Actually I just read Martin Fowler's article "Mocks aren't stubs" http://www.martinfowler.com/articles/mocksArentStubs.html. It's funny as I think I never used the term "mock" correctly...

      The way I understood the concept was: you take an object and you replace it by a proxy: - logical state is obtained by any means consistent with the logical invariants of the object; you can even have "mock" methods that do (almost) nothing...(like failing!)

      So okay, maybe in that sense "mock" methods are not pure stubs given that they must at least reach into something that changes the state of an object.

      In a way, the "final photo" is: you respect the messaging system, and bluntly change object data. Seems like thermodynamics, many paths are possible (and interesting, depending on what you want to test)

      If we focus purely on the external interactions of a program , that particular view that emphasizes state corresponds to treating everything "external" like a database. (In Quantum mechanics this concept is quite close to the concept of "picture" or perspective --Heisenberg picture, Schro"dinger picture, and mixed like the Furry picture-- there testing is the process of getting state but sometimes you want to emphasize the transitions and the "picture" helps then) Then when you start looking for more transparency, and an ORM for example gives you that: the database used is not important anymore; but still the real gain is when you push your abstraction one step further for total transparency: what is left are "datasets" (or set of) with many views (corresponding to different ways of serializing the data). So your database (and the tests!) is say your snapshot of xml before and after any state-changing call... and OO-zealots are just shooting me now;) but hey I still use object-based (black boxes and roles err...interfaces)

      hth --stephan
    		[reply]
        Actually I just read Martin Fowler's article "Mocks aren't stubs" http://www.martinfowler.com/articles/mocksArentStubs.html. It's funny as I think I never used the term "mock" correctly...

        I try (failing in this instance :-) to use the more generic term "test double" that Gerard Meszaros came up with rather than mock/stub/dummy/fake/whatever. See http://www.martinfowler.com/bliki/TestDouble.html.

    		[reply]

          thanks for the link; quite interesting.

          cheers --stephan
    		[reply]

    In Section Cool Uses for Perl