2

I've got a unit/integration test as follows.

using (var repository = _factory.Get())
{
    applicationBefore = repository.Applications
        .Include(a => a.AcceptedAgreements)
        .Single(a => a.AggregateId == applicationId);
}

// Perform an operation that deletes an Application and all
// related data and then rebuilds it from the event store.

Repo.Application applicationAfter = null;

using (var repository = _factory.Get())
{
    applicationAfter = repository.Applications
        .Include(a => a.AcceptedAgreements)
        .Single(a => a.AggregateId == applicationId);
}

applicationAfter.AcceptedAgreements.ShouldAllBeEquivalentTo(applicationBefore.AcceptedAgreements, options => options
    .ExcludingNestedObjects());

The repository reference is a DbContext and AcceptedAgreements is a navigation property.

This test fails with the following message.

Result Message: 
FluentAssertions.Execution.AssertionFailedException : 
Expected item[0].Application.Id to be 1, but found 2.
<more failures where stuff inside Application is different>

With configuration:
- Use declared types and members
- Compare enums by value
- Include all non-private properties
- Include all non-private fields
- Match member by name (or throw)
- Be strict about the order of items in byte arrays
- FluentAssertions.Equivalency.ShouldAllBeEquivalentToHelper+CollectionMemberOrderingRuleDecorator

If I modify the assertion as follows:

applicationAfter.AcceptedAgreements.ShouldAllBeEquivalentTo(applicationBefore.AcceptedAgreements, options => options
    .Excluding(o => o.Application));

Now the test passes.

Please help me understand why ExcludingNestedObjects() doesn't exclude the Application property, which is in fact a nested object, and I have to resort to excluding each navigation property individually. The above code is slightly simplified as I actually have multiple navigation properties and have to exclude each of them individually.

Craig W.
  • 17,838
  • 6
  • 49
  • 82
  • Which version are you using? – Dennis Doomen Oct 16 '15 at 06:07
  • @DennisDoomen: Best guess based on our source control is that it was 3.3.0 at the time. We're currently using 3.4.1 and I just tried changing the code back to use `ExcludingNestedObjects()` and it still fails the test but with a slightly different error. Rather than enumerating the differences between the two `Application` objects it just dumps both objects with an "expecting ... but found ..." message, which results in a test failure message that is ~30,000 lines long. If it would help I can send you the failure message but it's too large to post here. – Craig W. Oct 16 '15 at 14:59
  • Are you sure that you're using 3.4.1? It should have been fixed in 3.4.0: https://github.com/dennisdoomen/fluentassertions/commit/2c8a3e108c49e207a7c94d9a7e2079235cd1286f – Dennis Doomen Oct 16 '15 at 20:07
  • Yes, positive. Packages folder, packages.config, assemblies, all show 3.4.1. – Craig W. Oct 16 '15 at 20:43
  • Wait, just to be clear, `ShouldAllBeEquivalentTo` will compare the properties of each item in the source collection of the properties in the target collection. So, the fact that it compares the `Application` property of the first item with the equally named property of the second item is correct. What kind of object is `Application` pointing to? – Dennis Doomen Oct 17 '15 at 12:36
  • [This unit test](https://github.com/dennisdoomen/fluentassertions/blob/develop/Tests/FluentAssertions.Shared.Specs/CollectionEquivalencySpecs.cs#L718) should be doing the exact same thing (and passed obviously) – Dennis Doomen Oct 17 '15 at 12:56

0 Answers0