NH-3900 - Update to NUnit 3

[ngbrown]

This is for NH-3900.

There are a number of breaking changes between NUnit 2.x and NUnit 3.x, so this takes care of all of them.

NUnit 3 is doing more things in parallel, so this is driving some changes. Especially around the use of SetUpFixture in the NHibernate.Test.Linq namespace. Because NUnit 3 doesn't guarantee the order SetUpFixture in relation to tests in other namespaces, I had to separate the NHibernate.Test.Linq namespace into a separate assembly for it to run correctly.

There is not yet a GUI runner for NUnit 3, so the ShowBuildMenu.bat runs the console version with the appropriate command line switches to limit parallel assembly execution.

[samiraguiar]

There is a GUI runner for version 3:
https://github.com/nunit/nunit-gui

[ngbrown]

@samiraguiar The GUI for NUnit 3 is very much alpha/preview level of completion. I tried to use it, but it was quite unstable.

In the meantime, both Visual Studio's Test Runner and ReSharper work well with NUnit 3 tests.

[oskarb]

When possible, I think it's a good idea to make preparatory commits first, before introducing the changes the make the build or tests fail. To that effect, I've cherry-picked the changes for ExpectedException and Ignore() to master.

If there really is no other way than to move the linq tests to a separate assembly, that's also something that can be done before switching NUnit.

Anything else that can be merged before the actual switch?

[ngbrown]

@oskarb a lot of the changes were driven by exploration after updating to NUnit 3.x. Now that we know what it takes, I can work on re-ordering the commit sequence so any NUnit 2.x compatible changes get done first. This means things like TestCaseSource needing a static method, the obsolete NUnit contstrains and exception asserts will be able to be applied to the current master.

I tried numerous ways to get the Linq tests to run consistently in the same assembly, but because they have a different setup fixture with a database intended for read-only, it needed to be in a separate assembly so it would run at a different time. Time ordering wasn't intended to be guaranteed between SetUpFixture and tests outside of that namespace, so with NUnit 2.x, it was just luck that it worked.

Another alternative could be dynamically/randomly named databases generated per fixture. This would allow much more parallel testing, but with the static scripts, it seemed like a pretty big tear-up.

[hazzik]

I don't see any issues running linq in the same assembly. (UPD: I see now) However, the LinqReadonlyTestsContext was not updated to use [OneTimeSetUp] and [OneTimeTearDown] as it noted here: https://github.com/nunit/docs/wiki/SetUpFixture-Attribute, so it just did not work at all.

[ngbrown]

@hazzik Ya, sorry about the OneTimeSetUp missing, I lost that change when I re-based/cherry-picked the project split back to NUnit 2.x. I was about to push it to my branch but you had beat me to it.

[hazzik]

Here it says, that --workers=0 might solve the issue.

[ngbrown]

@hazzik I had seen that, but figured that the "still accidentally" meant it wasn't the way to go. It's up to you and @oskarb how, as maintainers, you want to handle this.

[maca88]

I can confirm that --workers=0 or [assembly: LevelOfParallelism(0)] does solve the problem. Here you can find my port to NUnit 3 without having to split into multiple assemblies.

[hazzik]

Hey, @ngbrown I'm going to resemble your PR with [assembly: LevelOfParallelism(0)], NuGet and NUnit 3.6

[hazzik]

Thanks for all the hard work.

See #550