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

David Chelimsky dchelimsky at gmail.com
Thu Feb 5 11:55:25 EST 2009

On Thu, Feb 5, 2009 at 10:17 AM, Ben Mabey <ben at benmabey.com> wrote:
> David Chelimsky wrote:
>> I highly recommend this blog post by Jay Fields:
>> http://blog.jayfields.com/2009/02/thoughts-on-developer-testing.html
>> Cheers,
>> David
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> Great post.  Very down to earth and realistic.
> This post raised a question for me.  Jay talks about how the pattern Object
> Mother gave way to Test Data Builders.  I use Fixjour ("Word to your object
> mother")[1], and other similar projects in my apps to provide a set of sane
> default attributes for my models.  You can then easily override those
> defaults by passing in a hash with the values that you need for the test.
>  After reading Nat's post about Object Mother vs Test Data Builders[2] , I
> have come to the conclusion that the "Object Mother" libs that are popular
> in ruby land (i.e. Fixjour, Factory Girl) are really more in line with the
> Test Data Builder pattern.  Does everyone agree with this conclusion or am I
> missing something?  It may be that I just use it differently, but according
> to Nat's post Test Builders provide a sane set of defaults that you can then
> explicitly override like so:
> Invoice invoiceWithNoPostcode = new InvoiceBuilder()
>   .withRecipient(new RecipientBuilder()
>       .withAddress(new AddressBuilder()
>           .withNoPostcode()
>           .build())
>       .build())
>   .build();
> Well.. this looks a lot like what I do in Ruby (but a lot more verbose):
> invoice_with_no_postcode = new_invoice(:recipient => new_recipient(:address
> => new_address(:postcode => nil)))
> Nat points out that problems with Object Mother arise when people start
> adding factory methods to deal with the edge cases, such as
> ObjectMother.new_invoice_with_no_postal_code.  I totally agree that this
> would be a problem since such abstraction results in hard to follow tests
> (this is why I hate fixtures actually).  From the projects I have worked on
> I haven't seen the Object Mother libs abused this way and they are used more
> like a Test Data Builder.  The only difference I see is in implementation,
> meaning the ruby libs tend to group all the factory methods on one object or
> module just like Object Mother, while the pattern Nat describes uses a
> separate builder class for each object.  I think this is really just details
> though and results from Ruby's differences from Java.
> Any thoughts?  Are Ruby's Object Mothers really Test Data Builders?

I'd say yes.

We also have a naming conflict in terms of test categories. The
definitions as I understand them are:

* Unit tests test units - generally one object at a time, or perhaps
more than one object that live within a single component, but never
crossing the component/layer boundary.
* Integration tests test integration - between two or more components.
* Functional tests test functionality - of the application as a whole
(more like cucumber scenarios)

By these definitions:

* what Rails calls unit tests are really integration tests (model and
database layers)
* what Rails calls functional tests are really bigger integration
tests (controller + model + database)
* what Rails calls integration tests are really functional tests
(scenarios that take you through routing)

Confused? Me too.


> -Ben
> 1. http://github.com/nakajima/fixjour/tree/master
> 2. http://nat.truemesh.com/archives/000714.html
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list