A colleague had a case where he needed to test the values assigned in an anonymous type returned by a class. With anyonmous types the .Equals() behaves a little a differently from typed objects. To paraphrase MSDN if, within the same assembly, two or more anonymous object initialisers define a sequence of properties that are equal in sequence, name and type the compiler treats them as instances of the same type. For example if we wrote the following test you would find it will pass.
On the other hand if we swapped the properties around on one of the initialisers the test would fail (in fact it would raise a compiler error).
But this not the real issue. As started previously, anonymous must be in the same assembly for them to be considered the same type. Given we have the following class in another assembly:
any attempt to validate the return value in a unit test will fail.
So what the solution?
A great tool for testing two instances of a given class to ensure that their property values are equal is FluentAssertions. FluentAssertions has a method called ShouldBeEquivalentTo() which does an object graph comparison. For example:
This also works for comparing two different classes that have the same properties such as comparing a dto with the source of the data.
So does this help with my colleague’s problem? Will yes it does but with one twist. By convention, with unit tests, we test the actual value against the expected value. For example actual.ShouldBeEquivalentTo(expected). When evaluating anonymous types we need to flip it around and test the expected value.