Panasonic Youth rob sanheim writes about software, business, ruby, music, stuff and things

Naming test objects - mock, stub, fake?

Martin Fowler recently posted about the confusion regarding what to name test doubles, and proposes a standard from Gerard Meszaros’ upcoming book. The names are as follows, with descriptions paraphrased from the using test double page at the books outline:

• Dummy Object: placeholder object that is passed to the code under test as a parameter but never used
• Test Stub is an object that is used by a test to replace a real component to force the system down the path we want for the test. A stub may also record info about how it was called (ie stub.wasMethodCalled() or stub.numberOfTimesMapResultSetCalled()
• Mocks fake implementation by returning hard coded values or values preloaded - they can also verify that the correct calls were made in the right order
• Fake objects replace the functionality of the of the real object with an alternate implementaiton, ie returning a canned list of values instead of hitting a database

I’m not sure if these names jive with what I am used to, but as long as the community can agree on some sort of consistent standard and stick with it I will happily adopt it. Trying to explain the difference between an EasyMock provided mock and a canned “fake object” gets tiring.

So a “Mock” returns hard coded values and a “Fake” returns a canned list of values.

That clears things up…

I just named an in memory database StubUserDao.

Doh!

to quote the source verbatim:
Mocks are pre-programmed with expectations which form a specification
of the calls they are expected to receive. They can throw an exception if
they receive a call they don’t expect and are checked during verification
to ensure they got all the calls they were expecting.
Fake objects actually have working implementations, but usually take
some shortcut which makes them not suitable for production (an
InMemoryDatabase is a good example).

i guess THAT clears things up. I am not sure why Rob needs to wrongly paraphrase Martin’s description, which is equally short, but much more to the point.

As a general rule of thumb I’d suggest: think before you blog, reconsider, and if just slightly in doubt: don’t blog. There’s absolutely no point in crowding goolge results with meaningless duplication or slightly more incorrect interpretation of the few valuable sources of information on the net.