Lunch and Learn

15/03/18

Test data generation

Aspect Oriented Programming using Spring

Test data generation

Consider an invoice object:

Constructing this object in application code may be done in one place, but in tests it becomes messy and hard to read when this object is created multiple times

Invoice invoice = new Invoice(
    new Recipient("Sherlock Holmes",
        new Address("221b Baker Street", 
                    "London", 
                    new PostCode("NW1", "3RX"))),
    new InvoiceLines(
        new InvoiceLine("Deerstalker Hat", 
            new PoundsShillingsPence(0, 3, 10)),
        new InvoiceLine("Tweed Cape", 
            new PoundsShillingsPence(0, 4, 12))));

Object mother

It can be tempting to create an object mother, TestInvoices

Invoice invoice = TestInvoices.newDeerstalkerAndCapeInvoice();

However this does not cope well with variations in test data

Invoice invoice1 = TestInvoices.newDeerstalkerAndCapeAndSwordstickInvoice();
Invoice invoice2 = TestInvoices.newDeerstalkerAndBootsInvoice();
...

Builders

A solution is to use the builder pattern

public class InvoiceBuilder {
    Recipient recipient = new RecipientBuilder().build();
    InvoiceLines lines = new InvoiceLines(new InvoiceLineBuilder().build());
    PoundsShillingsPence discount = PoundsShillingsPence.ZERO;

    public InvoiceBuilder withRecipient(Recipient recipient) {
        this.recipient = recipient;
        return this;
    }

    public InvoiceBuilder withInvoiceLines(InvoiceLines lines) {
        this.lines = lines;
        return this;
    }

    public InvoiceBuilder withDiscount(PoundsShillingsPence discount) {
        this.discount = discount;
        return this;
    }

    public Invoice build() {
        return new Invoice(recipient, lines, discount);
    }
}

Builders

Tests that don't care about the precise values in an invoice can create one in a single line

Invoice anInvoice = new InvoiceBuilder().build();

Tests that want to use specific values can define them inline without filling the test with unimportant details

Invoice invoiceWithNoPostcode = new InvoiceBuilder()
    .withRecipient(new RecipientBuilder()
        .withAddress(new AddressBuilder()
            .withNoPostcode()
            .build())
        .build())
    .build();

Combining Builders

Rather than calling build on each object, you can just pass the builder through

Invoice invoice = new InvoiceBuilder()
    .withRecipient(new RecipientBuilder()
        .withAddress(new AddressBuilder()
            .withNoPostcode())))
    .build();

Invoice invoiceWithNoPostcode = new InvoiceBuilder()
    .withRecipient(new RecipientBuilder()
        .withAddress(new AddressBuilder()
            .withNoPostcode()
            .build())
        .build())
    .build();

vs

Emphasise the domain model

We can de-emphasise the builders further by instantiating them in clearly named factory methods:

Order order = 
    anOrder().fromCustomer(
          aCustomer().withAddress(
              anAddress().withNoPostcode())).build();

This can be taken even further by renaming method names to reflect the relationship between objects only

Order order = 
    anOrder().from(aCustomer().with(anAddress().withNoPostcode())).build();

Emphasise the domain model

This relies on method overloading, but should only be done on objects with unique user defined types.

Primitive fields should have longer more descriptive names.

Address aLongerAddress = anAddress()
    .withStreet("222b Baker Street")
    .withCity("London")
    .with(postCode("NW1", "3RX"))
    .build();

Defining common state

you can initialise a single builder with the common state and then repeatedly call its build method

InvoiceBuilder products = new InvoiceBuilder()
    .withLine("Deerstalker Hat", new PoundsShillingsPence(0, 3, 10))
    .withLine("Tweed Cape", new PoundsShillingsPence(0, 4, 12));

Invoice invoiceWithDiscount = products
    .withDiscount(0.10)
    .build();

Invoice invoiceWithGiftVoucher = products
    .withGiftVoucher("12345")
    .build();

However you must be careful because objects built later will be created with the same state as those created earlier unless it is explicitly overridden

Defining common state

A solution is to add a method or copy constructor to the builder that copies state from another builder:

InvoiceBuilder products = new InvoiceBuilder()
    .withLine("Deerstalker Hat", new PoundsShillingsPence(0, 3, 10))
    .withLine("Tweed Cape", new PoundsShillingsPence(0, 4, 12));

Invoice invoiceWithDiscount = new InvoiceBuilder(products)
    .withDiscount(0.10)
    .build();

Invoice invoiceWithGiftVoucher = new InvoiceBuilder(products)
    .withGiftVoucher("12345")
    .build();

Aspect Oriented Programming

Separating these cross-cutting concerns from the business logic is where aspect oriented programming (AOP ) typically goes to work.

Weaving is the process of applying aspects to a target object. The weaving can take place at several points in the target object’s lifetime

Weaving

AOP terminology

Advice

The job of an aspect is called advice. Advice defines both the what and the when of an aspect.

Join Points

These are the points where your aspect’s code can be inserted into the normal flow of your application to add new behaviour. e.g. method calls, fields modified, exceptions thrown.

Writing Pointcuts

this - matching methods where the bean reference is an instance of the given type

@Pointcut("this(com.example.Foo)")

Combining Pointcuts

Pointcut expressions can be combined using

&&, || and ! operators