Re: [TDD] MockObjects
- Paul Christmann sez:
> Thoughts or comments or experiences? Thanks in advance for any feedback.The following meme is not widespread.
In the beginning of one's career, one does not mock, so we need to teach
In the beginning of a project, it needs lots of mocks as scaffolding to hold
up the ceiling before we put in the walls.
Now that programmers and programs grok Mocks, it's time to turn the tide.
A mature project should replace as many mocks with real objects as possible.
Expensive set-up is a design smell, so if replacing mocks with real objects
is hard, make it easy. Tune those objects until they are cheap to set up.
The brick wall at the end of reality here is modules that you can't control.
If you must plug into an iron hog, such as a database, or a sat dish, or a
fax machine, at this boundary you keep the mock, but promote it to the rank
-- The plasma signature at the end of the
wormhole is an approaching warbird --
> Here's what has worked for me so far:Both these lists were gear, so I put them here:
> a CounterObject - which counts the number of times a
> method has been called.
> a SaboteurObject - which throws exceptions and can be
> usefull to test the error handling.
-- DARE to resist drug-war profiteering --
> Another one I use often is a MockRandom class that returnsIf you are coding in Java, would setting the seed work, removing
> known values for nextInt() and similar functions so my tests
> don't have to account for randomness.
the need for a mock?
> If you are coding in Java, would setting the seed work, removingThis is not a Java question; all pseudo-random number generators can take a
> the need for a mock?
After seeding, rand() returns the same sequence in each set of times you
Between Refactoring and Adding Features there's a zone called "Changing
Features". In here, outside the pristine Refactoring rules, you might change
the order of functions that call functions that call your rand.
So suppose you have a Rogue-like game, where monsters move randomly. If a
test moves two monsters, and an otherwise harmless re-featurization changes
the order you call the two monsters, they'l pull different random numbers,
and now move in different directions. Your test broke for a false reason.
In this case, you might bond each Monster to its own MockRand. That way
re-featurizations are safer.
But the standard rand's seed is a singleton.
-- Temporomandibular joint disorder
keeping the neighbors awake again? --
- On Thu, 13 Mar 2003, Shaun Smith wrote:
> > Another one I use often is a MockRandom class that returnsPossibly. But first I'd have to set the seed and then run the RNG
> > known values for nextInt() and similar functions so my tests
> > don't have to account for randomness.
> If you are coding in Java, would setting the seed work, removing
> the need for a mock?
enough times to collect all the numbers it will return. Usually when I
make a mock it will return a set sequence of numbers like 1,2,3 or just
return one number every time. That way if I need to add more random
test cases or remove them I don't have to worry about the numbers.
Also, I don't know if there's a gaurantee that setting the seed will
always return the same numbers over different versions. If there isn't,
a change would cause the test to fail.
- --- In firstname.lastname@example.org, "Phlip" wrote
> test moves two monsters, and an otherwise harmless re-featurization
> the order you call the two monsters, they'l pull different randomnumbers,
> and now move in different directions. Your test broke for a falsereason.
Or the test broke for the right reason. When writing simulations,
having independent variables draw random numbers from independent
random number streams can be used to deal with issues like the above.
This is an interesting classification. I've certainly used all three kinds
of Mocks. However, in a recent project (see http://fitnesse.org) we made
very heavy use of Stub Mocks. These Mocks took on general, but very
simplistic, functionality. We were able to use them to test the overall
system, without using the resources that the non-mocks would use.
We also used Verifiable Mocks, but these turned out to be less useful for
our purposes. They got cluttered with 'do-nothing' implementations of
methods that were never called.
Robert C. Martin |
President & Founder |
Object Mentor Inc. | unclebob @ objectmentor dot com
PO Box 5757 | Tel: (800) 338-6716 x15
565 Lakeview Pkwy | Fax: (847) 573-1658
Suite 135 |
Vernon Hills, IL, | www.objectmentor.com
> -----Original Message-----http://docs.yahoo.com/info/terms/
> From: Paul Christmann [mailto:gcpt-testdrivendevelopment@...]
> Sent: Thursday, March 13, 2003 9:42 AM
> To: email@example.com
> Subject: [TDD] MockObjects
> Does anyone care to offer any opinions on use of MockObjects
> in a test
> I've found that I have used 3 different types of MockObjects in my
> testing, which I've made up names for.
> + Verifiable: MockObjects that allow me to verify that they were used
> appropriately. In particular, I use these for Listener objects (make
> sure they were notified) and "Connection" objects.
> + Empty: MockObjects that implement an interface with entirely null
> implementations (lots of empty methods, return null, return
> false, etc..).
> + Stub: Bigger than Empty, they actually implemented a bare
> minimum of
> functionality (i.e., if I needed to differentiate a return
> true from a
> return false, I implement a setter method to set a boolean value).
> I now believe that my Stub objects are a smell. I end up injecting
> behavior into a Mock to influence the behavior of the object
> under test.
> While for a trivial case (such as return true/false), that
> may not be
> a big deal -- I've found (as I review some of my Mocks with a more
> discerning eye) that it can be a slippery slippery slope one method
> here, one method there, soon I have a nearly fully functional Mock.
> I have found Verifiable Mocks so useful, I couldn't imagine a life
> without them. Two example use cases for them:
> + Stub an HttpConnection and inject an expected response. Then I can
> test client code Http handling (ability to get/set
> appropriate headers,
> content) without a server.
> + Test a ComponentA which has a ComponentB listener without having to
> drag in a ComponentB implementation (dragging in other unnecessary
> Now I'm casting a discerning eye on Empty. Why do I use
> them? Mostly
> in cases where an object has a method such as "useFoo(Foo
> foo)". But
> it seems to me that I am testing one of these things:
> a) Test a setter method (i.e., test setFoo(foo) and
> getFoo()). In that
> case, I really don't need a Foo, so a Mock could be useful. But why
> should I bother testing the setter (that's more of a
> rhetorical question)?
> b) Test that the provided Foo is called appropriately. But that is a
> Verifiable Mock, not an Empty Mock.
> c) Test that the provided Foo impacts the object-under-test.
> But this
> is a Stub, which I already am highly suspicious of.
> So as a result, I think that Empty Mocks may be a smell as well.
> Thoughts or comments or experiences? Thanks in advance for
> any feedback.
> Paul Christmann
> Prior Artisans, LLC
> ------------------------ Yahoo! Groups Sponsor
> Get 128 Bit SSL Encryption!
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to
> From: Paul Christmann [mailto:gcpt-testdrivendevelopment@...][snip]
> I've found that I have used 3 different types of MockObjects in my...
> testing, which I've made up names for.
> + Verifiable:
> + Empty:...
> + Stub:People have forgotten that mock objects are essentially stubs, and stubs
have been used for a variety of purposes and in different ways in testing
and development over the years. I would say stubs are a venerable general
category, and mock objects are a recently identified/invented specialization
of stubs specifically designed for "endo-testing" (a good term) in XP
methodology, as described in this paper