FluentAssertions.Properties

Unofficial FluentAssertions extensions for testing the behavior of class/struct/record properties.

Table of Contents

• How?
• Why?
• Installation
• Documentation

How?

Some common scenarios:

• Testing that all properties in a class provide symmetric access, i.e. they return the same value that has been assigned to them

    var instanceUnderTest = new SampleDto();
    var testValues = new Fixture().Create<SampleDto>();

    instanceUnderTest
        .Properties()
        .ThatAreWritable
        .WhenCalledWithValuesFrom(testValues)
        .Should()
        .ProvideSymmetricAccess();

Speaking in the lingo of AutoFixture, we can say that ProvideSymmetricAccess() verifies that the properteis are "well-behaved writables" (see AutoFixture's WritablePropertyAssertion idiom).

• Testing that getters/setters throw exceptions in certain cases

    var instanceUnderTest = new TestClass();
            
    instanceUnderTest
        .Properties()
        .ExactlyOfType<string>()
        .WhenCalledWith(string.Empty)
        .Should()
        .ThrowFromSetter<ArgumentException>()
        .WithMessage("Empty strings are not accepted.");

• Selecting specific properties to test by their type and value

    var instanceUnderTest = new TestClass();
            
    instanceUnderTest
        .Properties()
        .ExactlyOfType<string>()
        .HavingValue("some value")
        .Should()
        .HaveCount(2);

or selecting individual properties by name

    var instanceUnderTest = new TestRecord();
    string testValue = Guid.NewGuid().ToString();

    instanceUnderTest
        .Properties(o => o.StringPropertyOne, o => o.StringPropertyTwo)
        .WhenCalledWith(testValue)
        .Should()
        .ProvideSymmetricAccess();

A more comprehensive explanation of the selection and assertions methods, provided by this library, can be found here and here.

Why?

Even if code is trivial you should still test it.

-- Mark Seemann

Why should I consider testing my class properties?

From the perspective of the caller, the public properties are part of the public "interface" of a type. They imply a contract - their semantics is such that one expects them to behave like public fields. However, they have accessor methods, which can contain logic that modifies the expected behavior. Implementing nontrivial logic in the accessors is sometimes considered to be an anti-pattern, and rightfully so - in order for a programmer to see how a particular property behaves, they have to open the implementation of the type and look inside the code. The presence of accessor methods is a big part of the reason why Microsoft has provided a list of bad practices and design guidelines, concerning the implementation of properties.

But testing property accessors goes against the conventional wisdom!

There is a rule of thumb that says properties should not be tested if their getter and setter do not contain any logic, e.g. if they are auto-implemented. Robert C. Martin goes as far as to say that testing property accessors is foolish, regardless of whether their accessors contain logic or not. However, there are other prominent authors, such as Mark Seeman, who strongly disagree. And there seems to be a not-so-small minority, which thinks that testing all public properties is absolutely necessary.

Installation

This library is distributed as a NuGet.

To install FluentAssertions.Properties, run the following command in the Package Manager Console:

PM> Install-Package FluentAssertions.Properties

Or use this command with the .NET CLI:

> dotnet add package FluentAssertions.Properties

Documentation

• Property selector methods.
• Assertion methods.