Fakes aren’t stubs

May 7 2009

yep, title resembles Fowler’s article on interaction vs. state based testing. that was one of my first readings when i approached TDD, and soon i fell in love with mock objects. things change, of course, but that’s another story…

very close to my heart, there are “test doubles”, see Meszaros work on this. last xMas i also gave a presentation on that (a webinar to my colleagues in Amsterdam and Rome), and i tried to make clearer how and when to use doubles in tests. but i still missed one point.

testing in isolation. well, i want to test a bunch of code without depending on other parts of the application. in OO systems, code is moduled into classes. using Responsibility-Driven Desing terminology, you need to isolate tested class from responsibilities it collaborates with, which usually form one or more role.

while doing TDD, isolation isn’t a goal, but quite a medium: to add the smallest behaviour possible, you need to isolate from whatever isn’t stricly related to the task at hand. indeed, you often discover collaborations while wrinting an automatic test: roles emerge.

mock objects help on that: as the mockist fathers say, “mock roles, not objects”. hand-written mocks or dynamic mock object libraries are the way to go, choose one. these days, i’m with the former by default, and for using tools on more complex scenarios.

isolation can also be reached without the need to programmatically set behaviour (which is the essence of mock objects), relying on pre-set stubs, which usually behave in a default way (do nothing on void methods, return some simple, fixed values otherwise). stubs are really useful to simply ignore collaborations. if you want to, stubs can also be programmed, overriding default values.

then, it comes the time when you need to test a bunch of classes: say, integration tests which touch system boundaries, or acceptance tests focusing on domain, which don’t want to go live. of course, they’re coarse-grainer than unit tests. in these scenarios, you simply can’t mock-out collaborations. even more, you probably don’t want to.

to verify something has worked as expected, some real beaviour is needed: say, storing data on file instead of a RDBMS, reading input from a local file-system instead of an online storage, and the like. one of the best examples i’ve recently read is Pryce’s work on TDD of Asynchronous Systems, where he effectively substitute a few pieces of an application with fake ones.

in other words, fake objects are complete and consistent implementation of a given role (i.e. an interface). you just won’t probably use them into production code, even if they would do their job. most common example is an in-memory repository: store, update and retrieve objects in a coherent way. Fowler’s definition is:

“fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).”

sure, “fake” is not a great name! to get fakes less depressed and let them gain self-esteem, here’s my campaign: consider them first-class citizens, and please, stop calling them fake when you’re really just looking for a simpler, poorer, more stupid stub!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: