-
Notifications
You must be signed in to change notification settings - Fork 731
Description
Description
I'm currently migrating from 4.0.0 to 5.4.1 and stumbled across an issue that I first described at #860 (comment). I opened a new issue because it turned out, that this is not related to #860.
Using older versions of FluentAssertions (tested with 4.0.0) it was possible to compare a generic IEnumerable<T> to a non-generic IEnumerable using Should().BeEquivalentTo(). In 5.4.1 this throws an exception.
Complete minimal example reproducing the issue
The following code doesn't throw an exception in version 4.0.0:
List<Type> types1 = new List<Type> { typeof(int), typeof(string) };
IEnumerable types2 = new List<Type> { typeof(string), typeof(int) };
types1.Should().BeEquivalentTo(types2);In version 5.4.1 it throws an exception.
Workaround
As suggested by @jnyrup here the IEnumerable can be casted to IEnumerable<object> to make it work again:
types1.Should().BeEquivalentTo(types2 as IEnumerable<object>, options => options.RespectingRuntimeTypes());Expected behavior:
Same behavior as in version 4.0.0. The collections should be compared.
Versions
- FluentAssertions: 5.4.1
- .NET runtime: 4.7.2
- Target runtime: 4.5
Additional Information
The new behavior required me to change about 60 tests. That's ok, but maybe there are other projects where the effort is greater.
Also the blog post linked in the documentation says, that no changes are required for existing calls to Should().BeEquivalentTo(), when migrating to version 5:
You may wonder about that existing Should().BeEquivalentTo() that was available to collections. Well, that’s now behaving as a deep, structural comparison of collections. Existing calls will do exactly what it did before. It’ll just give you more information when the items in one collection don’t match those in the other collection.