A nice little trick with FluentAssertions

I love using FluentAssertions when writing tests for my code, it just makes the code so expressive in plain language. Recently I’ve been working on tests which involve the testing of lots of properties on a test result, and was looking for a way to remove a lot of the repetition involved.

Usually when asserting the properties on a test result, you can do it in three different ways. If I have my test class defined as below:

[TestFixture]

public class MyTestFixture

{

    private MyClass _subject; 

    private MyOtherClass _result;

    [SetUp]

    public void ExecuteTest() 

    { 

        _subject = new MyClass(); 

        _subject.Initialise(/*.. Some parameters here ..*/); 

        _result = _subject.SomeOperation();

    }

}

Then I can test the results as follows:

A. Assert all the properties in a test method

    [Test]

    public void ThePropertiesAreSet()

    {

        _result.First.Should().Be("Paula Bean");

        _result.Second.Should().Be("Brillant!");

    }

This is probably the usual way people do this. However, if the first test fails, the second test will never run, and we'll never know if our test method set the second result correctly or not, so we are lacking information as to the overall state of the test. Secondly, as the number of properties to test increases, you end up with a lot of visual noise, although Intellisense will at least take some of the effort out of creating the noise.

B. Assert the properties in a test method per property

    [Test]

    public void TheFirstPropertyIsSet()

    {

        _result.First.Should().Be("Paula Bean");

    }

    [Test]

    public void TheSecondPropertyIsSet()

    {

        _result.Second.Should().Be("Brillant!");

    }

With this approach, we now know if the setting of _result.Second was successful, even if _result.First failed. This extra information does come at the expense of more visual noise (the addition of another test method). Also, it allows you to really game the system if you get rewarded for the number of tests in your project :-)

C. Implement IEquatable

As the number of properties on MyOtherClass go up, you'll find a lot of code appearing in the test method. You can remove this by implemeting IEquatable<MyOtherClass> on MyOtherClass:

public class MyOtherClass : IEquatable<MyOtherClass>

{

    public override bool Equals(MyOtherClass other)

    {

        return this.First == other.First && this.Second == other.Second;

    }

}

(please note you should also really implement Object.Equals and Object.GetHashCode if you're going to use IEquatable, and for brevity, I've missed out a lot of the basic implementation of IEquatable<T>)

The result of this is that our test method now becomes:

    [Test]

    public void TheFirstPropertyIsSet()

    {

        MyOtherClass expected = new MyOtherClass { First = "Paula Bean", Second = "Brillant!" };

        _result.Should().Be(expected);

    }

Much cleaner and very expressive, and you'll probably find your code benefits elsewhere from having implementations of IEquatable<T>; but you do have to write that implementation (and perhaps unit test it too!). Yet more code...

This finally leads me to my point:

D. Use anonymous classes and FluentAssertion's AllProperties

How's this for simplicity?

    [Test]
    public void TheFirstPropertyIsSet()
    {
        _result.ShouldHave().AllProperties().EqualTo(new { First = "Paula Bean", Second = "Brillant!" });
    }

ShouldHave().AllProperties() does all the hard work of checking the properties. You can also use SharedProperties() if you only need to test a subset of the properties, and add IncludeNestedObjects if you have a more complex object model.

P.S. I love the story of the Brillant Paula Bean. It confirms all your prejudices about contractors.