Friday, February 08, 2008

Today I was creating a test data builder for a unit test. I am fairly new to test data builders, on the last project I was on I relied on the ObjectMother pattern which became fairly tedious over time. Both the ObjectMother pattern and the Test Data Builder are Test Helper patterns:

"We define a helper class to hold any Test Utility Methods we want to reuse in several tests." 

If your objects aren't immutable and all you really care about is getting sensible test data without having to repeat yourself, you can use the Rhino Mocks GenerateStub feature to provide sensible test data and deal with invariant test data:

 

[TestFixture]
public class InvoiceTests
{
    [Test]
    public void ShouldCreateInvoiceWithNoPostalCode()
    {
        Invoice invoiceWithNoPostalCode =
                new InvoiceBuilder()
                .WithRecipient(new RecipientBuilder()
                    .WithAddress(new AddressBuilder()
                        .WithNoPostalCode()
                        .Build())
                    .Build())
                .Build();
 
        Assert.AreEqual(string.Empty,
            invoiceWithNoPostalCode.Recipient.Address.PostalCode);
    }
 
 
}
 
public class InvoiceBuilder
{
    private Invoice invoice;
 
    public InvoiceBuilder()
    {
        invoice = MockRepository.GenerateStub<Invoice>();
    }
 
    public InvoiceBuilder WithRecipient(Recipient recipient)
    {
        invoice.Recipient = recipient;
        return this;
    }
 
    public Invoice Build()
    {
        return invoice;
    }
}
 
public class RecipientBuilder
{
    private Recipient recipient;
 
    public RecipientBuilder()
    {
        recipient = MockRepository.GenerateStub<Recipient>();
    }
 
    public RecipientBuilder WithAddress(Address address)
    {
        recipient.Address = address;
        return this;
    }
 
    public Recipient Build()
    {
        return recipient;
    }
}
 
public class AddressBuilder
{
    private Address address;
 
    public AddressBuilder()
    {
        address = MockRepository.GenerateStub<Address>();
    }
 
    public AddressBuilder WithNoPostalCode()
    {
        address.PostalCode = string.Empty;
        return this;
    }
 
    public Address Build()
    {
        return address;
    }
}

Once again be warned that this does not work for immutable objects, I don't recommend making value objects mutable just to implement this pattern so i'm not sure if it actually provides any real value. Maybe if it is combined with a mutable entity and a custom builder for a value object that preserves that value object's immutability. 

If anyone that reads this blog has a way to make Test Data Builders easier I would be glad to hear it.

 

[Currently Listening To: Young Galaxy- Young Galaxy - Wailing Wall]

Friday, February 08, 2008 6:56:17 AM (GMT Standard Time, UTC+00:00)  #    Comments [3]  | 
Tuesday, February 12, 2008 4:37:28 AM (GMT Standard Time, UTC+00:00)
Yes, some people do read your blog. :)

Immutable entities are initialized via their constructors. So I would collect all the parameters in member variables of the Builder and then create the immutable entity in the final call to Build.

Another cool trick to play is to implement an implicit cast between Builder and the object it is building. The implicit cast calls Build and returns the constructed object. Thus your fluent interface looks like this:

Invoice invoiceWithNoPostalCode =
new InvoiceBuilder()
.WithRecipient(new RecipientBuilder()
.WithAddress(new AddressBuilder()
.WithNoPostalCode()));
Wednesday, February 20, 2008 5:16:50 AM (GMT Standard Time, UTC+00:00)
James,

I never thought of using the implicit cast when using builders but it is pretty slick. I will post a follow up.
Thursday, February 28, 2008 10:02:27 PM (GMT Standard Time, UTC+00:00)
If your objects are mutable (in which case they are not value objects) and only expose property getters and setters, you don't actually need Test Data Builders at all.
Nat
Name
E-mail
Home page

Comment (Some html is allowed: a@href@title, strike) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Enter the code shown (prevents robots):

Live Comment Preview

Theme design by Jelle Druyts

Pick a theme: