Asserting Object Graph Equivalence Using Fluent Assertions 2.0
Selecting the right propertiesConsider the class Order and its wire-transfer equivalent OrderDto (a so-called DTO). Suppose also that an order has one or more Products and an associated Customer. Coincidentally, the OrderDto will have one or more ProductDtos and a corresponding CustomerDto. Now if you want to make sure that all the properties of all the objects in the OrderDto object graph match the equally named properties of the Order object graph, you can do this.
orderDto.ShouldBeEquivalentTo(order);In contrast to the ShouldHave() extension method, the comparison is recursive by default and all properties of the OrderDto must be available on the Order. If not, an exception is thrown. You can override this behavior in different ways. For instance, you may only want to include the properties both object graphs have:
orderDto.ShouldBeEquivalentTo(order, options => options.ExcludingMissingProperties());You can also exclude certain (potentially deeply nested) properties using the Excluding() method.
orderDto.ShouldBeEquivalentTo(order, options => options.Excluding(o => o.Customer.Name));Obviously, Excluding() and ExcludingMissingProperties() can be combined. Maybe farfetched, but you may even decide to exclude a property on a particular nested object by its index.
orderDto.ShouldBeEquivalentTo(order, options => options.Excluding(o => o.Products.Status));The Excluding() method on the options object also takes a lambda expression that offers a bit more flexibility for deciding what property to include.
orderDto.ShouldBeEquivalentTo(order, options => options .Excluding(ctx => ctx.PropertyPath == "Level.Level.Text"));This expression has access to the property path, the property info and the subject’s run-time and compile-time type. You could also take a different approach and explicitly tell FA which properties to include.
orderDto.ShouldBeEquivalentTo(order, options => options .Including(o => o.OrderNumber) .Including(o => o.Date));
Overriding and collectionsIn addition to influencing the properties that are including in the comparison, you can also override the actual assertion operation that is executed on a particular property.
orderDto.ShouldBeEquivalentTo(order, options => options .Using<DateTime>(ctx => ctx.Date.Should().BeCloseTo(ctx.Date, 1000)) .When(info => info.PropertyPath.EndsWith("Date")));If you want to do this for all properties of a certain type, you can shorten the above call like this.
orderDto.ShouldBeEquivalentTo(order, options => options .Using<DateTime>(ctx => ctx.Date.Should().BeCloseTo(ctx.Date, 1000)) .WhenTypeIs<DateTime>();The original ShouldHave() extension method does support collections now, but it doesn’t allow you to influence the comparison based on the actual collection type. The new extension method ShouldAllBeEquivalentTo() does support that so you can now take the 2nd example from the post and apply it on a collection of OrderDtos.
orderDtos.ShouldAllBeEquivalentTo(orders, options => options.Excluding(o => o.Customer.Name));
ExtensibilityInternally the comparison process consists of three phases.
- Select the properties of the subject object to include in the comparison.
- Find a matching property on the expectation object and decide what to do if it can’t find any.
- Select the appropriate assertion method for the property’s type and execute it.
- Choose the appropriate phase that the rule should influence
- Select the corresponding interface
- Create a class that implements this interface
- Add it to the ShouldBeEquivalentTo() call using the Using() method on the options parameters.
subject.ShouldBeEquivalentTo(expected, options => options .Using(new ExcludeForeignKeysSelectionRule()))That’s it for now. As usual, for questions, remarks or suggestions, you can use the Discussions page, StackOverflow, or you can contact me directly by email or Twitter.
Off topic: Although we’re still on CodePlex, the source code of Fluent Assertions is now stored in a Git repository. That should make it a whole lot easier for contributors to fork the code, write a nice improvement, and send us a pull request.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)