Test Driven - TDD'ers and mockists

[Charles Hasegawa]

Martin Fowler wrote an article about classic TDD'ers and "mockists". Which camp do you feel you fall into?

The long and the short of his article:

The big issue here is when to use a mock or other double...

The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn't really matter that much.

A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior. In this case for both the warehouse and the mail service...

The first thing to consider is the context. Are we thinking about an easy collaboration ... or an awkward one...? If it's an easy collaboration then the choice is simple. If I'm a classic TDDer I don't use a mock, stub or any kind of double. I use a real object and state verification. If I'm a mockist TDDer I use a mock and behavior verification. No decisions at all.

If it's an awkward collaboration, then there's no decision if I'm a mockist�I just use mocks and behavior verification. If I'm a classicist then I do have a choice, but it's not a big deal which one to use... The real issue is between classic and mockist TDD.

[edited to use a meaningful subject line - was "Question for Lasse Koskela"]
[ September 24, 2007: Message edited by: Jeanne Boyarsky ]

[Bill Peck]

Originally posted by Charles Hasegawa:
Martin Fowler wrote an article about classic TDD'ers and "mockists". Which camp do you feel you fall into?

The long and the short of his article:

[Bill Peck]

Originally posted by Charles Hasegawa:
Martin Fowler wrote an article about classic TDD'ers and "mockists". Which camp do you feel you fall into?

The long and the short of his article:

Sorry about the blank post.

Regarding Charles' question . . . Say a person was learning Java, but had a decent grasp of programming and software development. How many years of experience, generally speaking, would it take to have even the slightest clue of understanding of Charles' question?

[Charles Hasegawa]

Originally posted by Bill Peck:


Sorry about the blank post.

Regarding Charles' question . . . Say a person was learning Java, but had a decent grasp of programming and software development. How many years of experience, generally speaking, would it take to have even the slightest clue of understanding of Charles' question?

I apologize if that seems a bit ambiguous to anyone not familiar with the terms MF uses, or his article...
TDD = Test Driven Development
Stub (as it applies to test) = a class that is created (typically) to fulfill a type contract (like a class implementing an interface) yet really has very little to it other than signatures and one or two "implemented" methods.
Mock (as it applies to test) = another "fake" object that implements an interface and can mimic behaviors desirable to a tester.

Basically, as OOP has matured, so has (in some cases) the complexity of the objects we create (or in some cases like J2EE - forced to create). With that complexity, you optimal will try to create objects that are very specialized, but at some point you will reach critical mass and need to create something that ties everything together. Unit tests for the individual pieces are straight forward, but more complex objects are harder to nail down. By using mocks and/or stubs, a developer writing a test has control over what a certain object will do and how it will act, thus taking one "variable" out of the equation. What MF talks about is whether the goal of a unit test on this type of object should be to test the behavior of the object vs the state of the system. A "classic" TDD'er says, "I know the state before and all I care about is the state of the system after for various inputs". A "mockist" says that how everything interacts is equally important in complex systems (you still have to get the right answer of course).

So, going back to the question at hand - I'm curious about the author's opinion, as it gives some small insight to their general approach to testing.
[ September 24, 2007: Message edited by: Charles Hasegawa ]

[Lasse Koskela]

Charles, I guess I'm neither as I tend to mix and match state and interaction-based tests. Generally speaking, I lean more on interaction-based tests the more complex the objects involved become.