Restore basic assertions for collections in System.Data

[logiclrd]

In anticipation of the new functionality to allow excluding non-browsable fields (#1807), I updated our project to the latest published version and discovered that about 9 months ago, assertions on non-generic collections were removed from FluentAssertions. Unfortunately, DataSet and DataTable were codified before generics existed and have only non-generic collections. As such, assertions on these collections depended on the existing blanket non-generic collection functionality. With this removed, our test suite no longer compiles because of assertions such as,

result3.Rows.Should().BeEmpty();

This PR addresses this issue by wrapping the three collections involved in System.Data in a class that implements IEnumerable<T>, so that the assertions in GenericCollectionAssertions<T> can apply. In addition, some additional assertions are provided that take System.Data types as arguments.

This PR also includes updates to the release notes and documentation, as well as comprehensive automated testing of the new functionality.

IMPORTANT

• The code complies with the Coding Guidelines for C#.
• The changes are covered by unit tests which follow the Arrange-Act-Assert syntax and the naming conventions such as is used in these tests.
• If the PR adds a feature or fixes a bug, please update the release notes with a functional description that explains what the change means to consumers of this library, which are published on the website.
• If the PR changes the public API the changes needs to be included by running AcceptApiChanges.ps1 or AcceptApiChanges.sh.
• If the PR affects the documentation, please include your changes in this pull request so the documentation will appear on the website.

[dennisdoomen]

Wow. Wasn't it easier to use Cast<T> instead?

[logiclrd]

We already have a suite of tests which I'd prefer to touch only if strictly necessary, and using Cast<T> doesn't have compile-time type safety.

[logiclrd]

The new assertions types and corresponding tests are very closely based on the existing collections assertion code; this is not created out of whole cloth, but out of copy/pasting the existing code and then massaging it to the types in question. :-)

[dennisdoomen]

Sorry, what I meant is that your new Should() methods would return the generic assertions by casting the non-generic collection to a generic-collection and then passing that to GenericCollectionAssertions.

[logiclrd]

Mm, that would provide part of the functionality. But, it wouldn't have things like ContainTableWithName and it would include a bunch of assertions that aren't relevant, such as NotBeNull.

[logiclrd]

Of course, there's no pre-existing code calling those methods. But given all the other System.Data-specific sets of assertions, this seemed the logical way to do it. Casting the collection and using GenericCollectionAssertions didn't occur to me, to be honest, but if it had, I think I still would have gone this route.

[dennisdoomen]

Mm, that would provide part of the functionality. But, it wouldn't have things like ContainTableWithName and it would include a bunch of assertions that aren't relevant, such as NotBeNull.

You could provide those as an extension method on GenericCollectionAssertions<DataSet> or something like that.

It's more to avoid too much duplication and maintenance on our side.

[logiclrd]

Hmm, that's true :-) I'll investigate that.

[logiclrd]

One thing with that approach is that after .Cast<DataTable>, the true subject's type is lost. The only way to check if the DataSet contains a table with the specified name, for instance, is to enumerate it; that's what .Contains will do on assertion.Subject, since it's an anonymous IEnumerable<DataTable> at that point wrapping the actual collection. DataTableCollection's own Contains method takes advantage of its internal data structure.

[dennisdoomen]

Is that a real issue? How many tables does a data set typically contain? I guess 50 is already quite a lot.

[jnyrup]

In it's current state I think this is duplicating too much functionality.
To be bluntly honest I still occasionally wonder whether #1419 should have been included in the core library.
Not to dishonest your work and contribution, but the truth is that the burden of support is left on @dennisdoomen and me.
E.g. #1068 (comment) revealed that #1419 seems to have a lot of untested cases.
Related blog post: https://blog.jessfraz.com/post/the-art-of-closing/

[logiclrd]

@dennisdoomen That's true... Is there no other situation where the loss of the subject type would be an issue?

[dennisdoomen]

To be bluntly honest I still occasionally wonder whether #1419 should have been included in the core library.

Have the exact same feeling. In retrospect, we should have decided to make it a supporting library that is maintained by others.

[dennisdoomen]

Is there no other situation where the loss of the subject type would be an issue?

Can't think of anything right now.

[logiclrd]

I was hoping to get this in before the end of your day, but it was just too late for me. :-) Here's a rewrite that leverages GenericCollectionExtenions<TData>. I found that I still had to explicitly implement the equivalency checks for DataRow because what GenericCollectionExtensions does by default doesn't have the same semantics. But, there's a lot less code now!

[dennisdoomen]

While looking at the implementation and thinking of the repercussions of us maintaining this, I thought of another solution:

internal class EnumerableWrapper<T, TItem> : ICollection<TITem>, where T : ICollection

Then this wrapper delegates properties like Count to the wrapped part. Then instead of using Cast<TItem, you pass new EnumerableWrapper<DataTable, DataColumn>

Since Enumarable.Count() is smart enough to see that an IEnumerable<T> is really a collection, you don't get the penaalty.

[logiclrd]

That sounds promising! I'll give that a go.

[logiclrd]

Hmm, one problem: The non-generic ICollection is really sparse and doesn't have a Contains member. Could still be possible to have specialized implementations for the 3 collection types in question.

[logiclrd]

Huh, I think Visual Studio must have been acting up. IntelliSense was initially telling me that the non-generic interfaces didn't expose a Count method at all. So, I came up with the scheme in 68c839e that allows an abstract member to be implemented by collection-type-specific subclasses.

But, I kept poking at it because this didn't make sense to me and suddenly Count started showing up in IntelliSense. I'm confused, but I've reworked it to not need the collection-type-specific subclasses.

[logiclrd]

There, I think that commit is what you had in mind, and it solves the problem elegantly. Thank you :-)

[dennisdoomen]

The non-generic ICollection is really sparse and doesn't have a Contains

What if you used InternalDataCollectionBase instead of ICollection?

[logiclrd]

What if you used InternalDataCollectionBase instead of ICollection?

The problem is more fundamental -- the Contains method overloads that I really care about are the ones that check for DataTable by TableName and DataColumn by ColumnName, and those can't be in common. DataRowCollection doesn't even have an analog for it at all. So, instead, I took advantage of the fact that the new wrapper class allows the underlying object to be inspected, and the assertions that want to call Contains simply call it directly on the underlying DataTableCollection or DataColumnCollection.

[dennisdoomen]

So, instead, I took advantage of the fact that the new wrapper class allows the underlying object to be inspected, and the assertions that want to call Contains simply call it directly on the underlying DataTableCollection or DataColumnCollection.

Fair enough. Let us know when you're ready for the formal review ;-)

[logiclrd]

I don't think I have anything outstanding on my end at this point.

[dennisdoomen]

Some general notes before I can continue the review:

• I suspect a lot of the methods on the new extension classes are no longer needed
• The unit tests need to be updated to take into account some of the comments we had on #1807

[dennisdoomen]

It's a big enhancement, albeit quite niche, so there is a lot of work to be done to finish this. I hope you're up for it.

FYI, just assume that my code review comment apply to all other code as well, so please be thorough.

[logiclrd]

(rebased to resolve release.md conflict)

[jnyrup]

Sorry for the delayed review.
I gave it another look and it looks good.