Seems there are an awful lot of breaking changes in NUnit 4

Yes I also tried NUnit 4 at first and saw the amount of breaking changes, so I reverted to the latest 3.x version.
I also don't really understand the error we are getting, and why everything is fine on Azure but not on GitHub Actions. Will look into it some more later.

Encountered infinite recursion while looking up resource 'Arg_NullReferenceException' in System.Private.CoreLib. Verify the installation of .NET is complete and does not need repairing, and that the state of the process has not become corrupted.

Don't think I've seen that before; dotnet/runtime#72381 has some commentary on it: maybe it's a clue

At least one of net8.0-windows tests (OxyPlot.Wpf.Tests) are failing for me locally when run with dotnet test: seeing the same infinite recursion error, but not much that is diagnostically useful, and it's not deterministic. It looks like a window is briefly trying to open before it dies. Everything else (e.g. net8.0 and net6.0-windows) seems to be OK.

Also had some sort of weird error state trying to run the WPF tests for net8 in Visual Studio also, but VS seemed at least as confused as me so don't want to read too much into that.

Documenting my findings so far, mostly so I will remember them myself:

• This is very weird
• The error occurs while running OxyPlot.Wpf.Tests
• It happens only for .NET 8, not for .NET 6, .NET 7 or Framework 4.6.2
• I can reproduce the crash with same error message on my local Windows 11 machine by running dotnet test Source/OxyPlot.Wpf.Tests/OxyPlot.Wpf.Tests.csproj --configuration Release from command line
• The crash does not happen when PlotViewTests are excluded from the test run (but all other tests are included)
• The crash does not happen when PlotViewTests are run individually
• It does not happen when running the tests via Visual Studio Test Explorer

Will continue to investigate later.

Repro'd everything you describe on my Win10 machine. Further, it seems not to occur in any of the following situations:

• comment out the two tests that try to open a window
• remove the [RequiresThread(System.Threading.ApartmentState.STA)] attribute on the same two tests
• change RequiresThread attribute to Appartment on the same two tests

It's been years and years since I had any idea what STA and MTA had to do with anything, but I also tried disabling just one of the tests (RequiresThread suggests it will always start a new thread, and that sounds problematic for STA) and that didn't help. I can't find anything about this after a quick search, but the third option seems like a reasonable thing to try to see if it makes the CI happy.

I think the RequiresThread attribute can just be removed. All tests run in STA mode anyway because of [assembly: Apartment(ApartmentState.STA)] in AssemblyInfo.cs.
I don't quite understand why this would lead to the kind of crash we had here, but at least locally this fixes it. Let's see what the CI thinks about it.

This seems to have done the trick 🥳