Specifying [readonly] property values [via ctor args] when instantiating [immutable] objects with AutoFixture

Question

My test requires that I set the Response property on an immutable Rsvp object (see below) to a specific value.

public class Rsvp
{
    public string Response { get; private set; }

    public Rsvp(string response)
    {
        Response = response;
    }
}

I initially tried to do this using Build<Rsvp>().With(x => x.Rsvp, "Attending"), but realized this only supports writable properties.

I replaced that with Build<Rsvp>().FromFactory(new Rsvp("Attending")). This works, but is cumbersome for more complex objects where it doesn't matter what some of the properties are.

For instance, if the Rsvp object had a CreatedDate property, this method of instantiating the object would force me to write Build<Rsvp>().FromFactory(new Rsvp("Attending", fixture.Create<DateTime>())).

Is there a way to only specify values for meaning properties for an immutable object?

Eldridgeeldritch

Related: https://mcmap.net/q/590143/-autofixture-generate-custom-list – Prominence

Build<T>().FromFactory(Func<T> factory) throws InvalidCastException when I try it. Does this still work in AutoFixture 4.0? – Toadinthehole

Answer 1

AutoFixture was originally build as a tool for Test-Driven Development (TDD), and TDD is all about feedback. In the spirit of GOOS, you should listen to your tests. If the tests are hard to write, you should consider your API design. AutoFixture tends to amplify that sort of feedback.

Frankly, immutable types are a pain in C#, but you can make it easier to work with a class like Rsvp if you take a cue from F# and introduce copy and update semantics. If you modify Rsvp like this, it's going to be much easier to work with overall, and thus, as a by-product, also to unit test:

public class Rsvp
{
    public string Response { get; private set; }

    public DateTime CreatedDate { get; private set; }

    public Rsvp(string response, DateTime createdDate)
    {
        Response = response;
        CreatedDate = createdDate;
    }

    public Rsvp WithResponse(string newResponse)
    {
        return new Rsvp(newResponse, this.CreatedDate);
    }

    public Rsvp WithCreatedDate(DateTime newCreatedDate)
    {
        return new Rsvp(this.Response, newCreatedDate);
    }
}

Notice that I've add two WithXyz methods, that return a new instance with that one value changed, but all other values held constant.

This would enable you to create an instance of Rsvp for testing purposed like this:

var fixture = new Fixture();
var seed = fixture.Create<Rsvp>();
var sut = seed.WithResponse("Attending");

or, as a one-liner:

var sut = new Fixture().Create<Rsvp>().WithResponse("Attending");

If you can't change Rsvp, you can add the WithXyz methods as extension methods.

Once you've done this about a dozen times, you get tired of it, and it's time to make the move to F#, where all that (and more) is built-in:

type Rsvp = {
    Response : string
    CreatedDate : DateTime }

You can create an Rsvp record with AutoFixture like this:

let fixture = Fixture()
let seed = fixture.Create<Rsvp>()
let sut = { seed with Response = "Attending" }

or, as a one-liner:

let sut = { Fixture().Create<Rsvp>() with Response = "Attending" }

Prominence

+1 If @mattslav can modify the Rsvp class (or add the extension methods) then this should be the accepted answer. – Stead

The first paragraph of this answer is so well written that we could actually include it in description at AutoFixture's README file. – Stead

With records in F# you loose the ability to define invariants on the properties. You might want to limit the shape of a string property to a subset of all strings. This is where classes shine. – Calcaneus

I wouldn't say the tests are hard to write. I wasn't sure the best way to implement the Object Builder pattern using AutoFixture as the engine for creating objects. Using extension methods that are only available to tests seems to be the best option, as this is something that only tests need to be able to do. – Eldridgeeldritch

@mattslav Sure you can add it as test-only code, but IME, it's a valuable feature to have in production code too. The benefit of TDD is that it gives you feedback about the production API of your code. – Prominence

@MarkSeemann In your Rsvp implementation, it looks like you have the same capabilities (including chaining) as if you'd implemented a nested RsvpBuilder class that had WithXyz() methods. Does the nested builder do nothing more, then, than to encapsulate the creation logic, and (if the Rsvp constructors are made private) ensure its status as 'sole entry point' into Rsvp construction? – Saxecoburggotha

@MarkSeemann Also, by keeping the Rsvp constructor public, while preserving immutability, is this what permits Autofixture to still create these immutable objects for us without complaining about '...no public constructor, is an abstract or non-public type...'? – Saxecoburggotha

@Lumirris With a copy-and-update API, the class becomes its own Builder, so that you don't need a separate Builder. I much prefer this pattern, as it's more succinct. FWIW, I stole the idea from F#. Keeping the constructor (and the class itself) public means that it's just a 'normal' concrete class, and AutoFixture deals with those without further needs for extensions or customizations. It's poka-yoke design: blog.ploeh.dk/2011/05/24/Poka-yokeDesignFromSmelltoFragrance – Prominence

@MarkSeemann In a scenario in which object instantiation is expensive, doesn't this approach become less desirable as more calls to WithAbc, ... WithXyz are made (and new instances created with each call?). Or is this simply a balance that must be struck when one needs immutable classes? – Saxecoburggotha

@MarkSeemann I'm familiar with your Poka-yoke blog series; which of the 5 parts of the series specifically deals with the issue here (if any) - I couldn't figure that out. – Saxecoburggotha

@Lumirris What sort of scenario is it where object instantiation is expensive? – Prominence

@MarkSeemann Heh heh. I guess you called my bluff, as I can't think of any specific example, but... aren't there scenarios in which it would be expensive? I guess something just felt wrong to me seeing new instances being created for each chained WithXyz call, when many calls are made... – Saxecoburggotha

@Lumirris Unless you go out of your way to make instantiation expensive, it's not. blog.ploeh.dk/2011/03/04/Composeobjectgraphswithconfidence – Prominence

While I agree that F# is a better way to go, unfortunately my group isn't willing to have production F# code yet, so I'm stuck with C#. However, I have gotten buy-in of immutable types. When testing with these, it can be very handy to have an anonymous variable with a specific property set to a specific value. For example, when using a Parameter Object I may want to write a test for when x.Foo == True and another for when x.Foo == False, but this is a pain if there are a lot of properties on x. In this case we don't need production copy-and-update code for x, only for testing. – Sightseeing

Answer 2

As long as the Response property is readonly^*, you can define a custom SpecimenBuilder for the Rsvp type:

internal class RsvpBuilder : ISpecimenBuilder
{
    public object Create(object request, ISpecimenContext context)
    {
        var pi = request as ParameterInfo;
        if (pi == null)
            return new NoSpecimen();

        if (pi.ParameterType != typeof(string) || pi.Name != "response")
            return new NoSpecimen();

        return "Attending";
    }
}

The following test passes:

[Fact]
public void ResponseIsCorrect()
{
    var fixture = new Fixture();
    fixture.Customizations.Add(new RsvpBuilder());
    var sut = fixture.Create<Rsvp>();

    var actual = sut.Response;

    Assert.Equal("Attending", actual);
}

---

^* If for some reason the Response property becomes writable you can follow the solution in this answer.

Stead

I was hoping for a solution that didn't require an object builder to be created for every object. Additionally, the test would need to pass the Response value to the RsvpBuilder, how would it do that? – Eldridgeeldritch

@mattslav Is is possible as Mark Seemann answered. – Stead

Answer 3

Extending Nikos´ answer, we can generalize the customization to work with any property as such:

public class OverridePropertyBuilder<T, TProp> : ISpecimenBuilder
{
    private readonly PropertyInfo _propertyInfo;
    private readonly TProp _value;

    public OverridePropertyBuilder(Expression<Func<T, TProp>> expr, TProp value)
    {
        _propertyInfo = (expr.Body as MemberExpression)?.Member as PropertyInfo ??
                        throw new InvalidOperationException("invalid property expression");
        _value = value;
    }

    public object Create(object request, ISpecimenContext context)
    {
        var pi = request as ParameterInfo;
        if (pi == null)
            return new NoSpecimen();

        var camelCase = Regex.Replace(_propertyInfo.Name, @"(\w)(.*)",
            m => m.Groups[1].Value.ToLower() + m.Groups[2]);

        if (pi.ParameterType != typeof(TProp) || pi.Name != camelCase)
            return new NoSpecimen();

        return _value;
    }
}

But then we need custom extension methods to make it easier to use:

public class FixtureCustomization<T>
{
    public Fixture Fixture { get; }

    public FixtureCustomization(Fixture fixture)
    {
        Fixture = fixture;
    }

    public FixtureCustomization<T> With<TProp>(Expression<Func<T, TProp>> expr, TProp value)
    {
        Fixture.Customizations.Add(new OverridePropertyBuilder<T, TProp>(expr, value));
        return this;
    }

    public T Create() => Fixture.Create<T>();
}

public static class CompositionExt
{
    public static FixtureCustomization<T> For<T>(this Fixture fixture)
        => new FixtureCustomization<T>(fixture);
}

we then use it in your example as:

var obj = 
  new Fixture()
    .For<Rsvp>()
    .With(x => x.Response, "Attending")
    .Create();

Blaze

I've tried this, pi.Name != camelCase is always true, because pi.Name is always "value". Any idea why that is? – Dancy