[rspec-users] [OT] Object Mother vs Test Data Builder (was Jay Fields' blog on developer testing)

Pat Maddox pergesu at gmail.com
Thu Feb 5 19:20:42 EST 2009

On Thu, Feb 5, 2009 at 8:17 AM, Ben Mabey <ben at benmabey.com> wrote:
> Any thoughts?  Are Ruby's Object Mothers really Test Data Builders?

Here's what I think is important:

* Make fixture setup explicit by inlining it on a per example/group basis
* Keep fixture setup short by hiding the object graph construction
* Allow concise parameterization of the fixture objects
* Focus 100% on structure (0% on behavior) in methods/objects to build
your data.  This minimizes accidental coupling between examples.

The name you give a tool that fulfills these goals is never going to
be central to valuable conversation, so I think it's of minimal

The rest of this email is somewhat ranty, and originally appeared
before what you just read above...but I figured I'd save some people
time and separate it out so you can skip over it if you want :)


I don't know what the distinction is, and to tell you the truth I
don't think it matters.  There's miniscule evidence to suggest that
these are fundamentally different (quotes from

1) These canned objects often aren't just right for a particular test,
but often can be made right with some additional setup

Okay, but he doesn't say HOW that additional setup comes about.  Do
you get an object from the mother and then call some setters on it?
Do you parameterize calls to the OM?  You can do either of those with
all of the fixture replacement tools that I know of.

2) The canned objects that the Object Mother produces become familiar
to the team, often invading even discussions with the users

I guess this is where the "mother" thing comes from...mothers have
children, children are unique like snowflakes and have names and
personalities and yadda yadda.  Personally I think that cast of
characters blows as a testing pattern.  It always leads to inadvertent
coupling between tests and muddles intent.  What makes more sense to
you as a developer, "that customer object in this test is Joe Bob" or
"that customer object is a customer with an account balance of $10k".

If you want to get into pattern specifics, the question really is "am
I using factory methods or a builder," to which the answer is "factory
methods" for every tool I've seen.  Well, not quite.  You can imagine

new_user :name => "Pat", :email => "pat.maddox at gmail.com"

is a different form of

UserBuilder.new.with_name("Pat").with_email("pat.maddox at gmail.com").build


def new_user(options={})
  options.inject(UserBuilder.new) {|b,pair|
b.send("with_#{pair.first}", pair.last) }.build

A beautiful outcome of using Ruby is that many traditional patterns
fade in importance.

If you want to be very technical, these tools are neither Object
Mothers nor Test Data Builders right out of the box (assuming that TDB
uses the actual Builder pattern).  Rather, they're just
factories/factory methods, dynamically generated by reflecting on
given classes.

The real question is which one communicates better.  I'd say TDB does
because it says exactly what it is - it builds data for your tests.
You could use it in a conversation and the other party would not need
to know that it's a pattern of any kind.

But...Rails has fucked up the testing lexicon for tons of Ruby
programmers.  There's already a lot of fuzziness between
unit/functional/integration in the testing community as a whole, and
as David pointed out it's made worse in the Rails world by how *wrong*
Rails gets the names.  So when I talk to people I strictly use
"developer tests" and "acceptance tests."  I find that a much more
valuable distinction to make.  And for developer tests, it makes a lot
more sense to discuss them in terms of value and tradeoffs than it is
to try to put them in certain buckets.  How does that fit into this
discussion?  Well, to me, a fixture is a set of objects in known
states that comprise the context in which a test runs.  To lots of
Rails developers, fixtures are yaml files that define records in the
test db.  Instant communication problem, because it implies the
question is Fixjour vs Foxy fixtures, which is absolutely not the


More information about the rspec-users mailing list