Re-add "legacy" Assert methods

[MgSam]

I know this is going to be controversial. However, I strongly recommend re-adding the "legacy" Assert/CollectionAssert/StringAssert methods (eg, Assert.Equal).

I believe Assert.That is objectively worse in every respect. In pre 4.0 versions, when you type Assert and then a dot, you get Intelliense for all the possible overloads (Equals, LessThan, etc). They are simple and straightforward to use. You do not need to go look up documentation.

Assert.That is the complete opposite. You have to "know" that the second argument requires a magical "Is" or "Does" construct. If you want to do something more complex you may have to chain multiple extremely undiscoverable method calls like Is.Not.... You are basically required to implicitly understand lots of extra-linguistic constructs that NUnit has added.

I understand that some people find the "That" syntax more pleasant to read. But I think it is way more difficult to write, way less discoverable, and a huge downgrade in usability for this library.

The main reason I and others have continued to prefer NUnit over XUnit is the superior simplicity and usability. Removing the easily discoverable methods we've all known and loved for decade(s) is a huge mistake, IMHO.

[OsirisTerje]

They are still there, just under a name ClassicAssert. And if you want that to use the Assert, you can actually change that yourself using an alias, ref Using global using aliases, either as a global alias in the GlobalUsings.cs file, or directly in the csproj file.

global using Assert = NUnit.Framework.Legacy.ClassicAssert;

or in the csproj

<Using Include="NUnit.Framework.Legacy.ClassicAssert" Alias="Assert" />

You can then still use the That syntax if you like, in some cases.

We have no intention of removing these, but I assume you have read that we can't evolve the classic asserts the way we can with the constraint aliases.

[MgSam]

Why rename them though and break everyone who upgrades?

[OsirisTerje]

We had to move them into a separate project.
We also considered moving it into its own project, but that is now on ice. But splitting out all assertions, including constraints, into their own packages does have merit.
And when it is in its own project, we can't have the same class name.

If C# had allowed extension methods on static classes (which have been discussed for one, and also here ), we could have solved it that way.

Also, this is a version 4, it does come with breaking changes, and that's also why we have a Migration Guide.