NUnit 3.x support

[fsprojects]

NUnit 3.x support

[sergey-tihon]

Yes, we need FAKE support of NUnit3 first
fsprojects/FAKE#1010

[sergey-tihon]

So, probably it is time to try to support of NUnit 3 fsprojects/FAKE#1064

[sergey-tihon]

@et1975 do you have experience of writing custom constrains for NUnit3?

[et1975]

I wanted to take a look at v3 anyways, might as well port this.

[sergey-tihon]

Thank you @et1975

[et1975]

Once nunit/nunit#1196 is resolved the changes in et1975/FsUnit/equals branch should do it.

[rprouse]

The NUnit team is working on custom message formatters based on the issue nunit/nunit#1196 and original PR by @et1975. @CharliePoole has create PR nunit/nunit#1222

This fix is intended for you, so we would appreciate a code review to see if it meets your needs.

Once it is merged, if you need to test using the NuGet packages produced by our continuous build, I can point you to them.

@sergey-tihon what do you need custom constraints for? They are fairly easy to write. If you need help, please reach out.

[CharliePoole]

Here's another question about our (NUnit's) support for F#.

Can anybody think of a way to add a feature to the NUnit framework, so that it is only accessible to F#. Resolving nunit/nunit#1196 with a static global is cool for F# users, who will access it in a top-level module, rather than from a test. It's a bit more dangerous in C# (not to mention VB) where calling it from within a test is the most natural way to do it. Adding a new formatter inside a test using the a static method creates a nasty side-effect.

Maybe we need a separate module per language on top of the framework, but that's a very busy solution. Which is what leads to the question: how to give something to F# users without giving it to other users?

[sergey-tihon]

@rprouse
Would be nice to test in once it is merged. Appreciate if you point me to you nightly packages.
There are only two custom constrains in current codebase:

• EqualsConstraint - we use it to pretty-print F# values
• ChoiceConstraint which allow us to write constrains for F# Core.Choice<'T1,'T2> values, like

Choice<int, string>.Choice1Of2(42) |> should be (choice 1)

@CharliePoole I think that the reason why @et1975 did not want to do it in OneTimeSetUp is that we can do it once per assembly with static method.
Users of FsUnit can get it for free because it will be in FsUnit.dll and that is enough.

[CharliePoole]

@sergey-tihon It sounds like F# users are likely to be satisfied by this. My concern is that we are exposing the feature to all users and those working in other languages who use this in the most "obvious" way will be unexpectedly impacting global state. That is, such users are likely to call the method in a setup or onetimesetup. They will expect the custom format to go away when the scope of the setup terminates but that won't happen.

In fact F# users could fall into the same trap but probably won't because they have an easier way to use the feature.

I'll keep playing with this and let you know when there is something relatively final to test.

[rprouse]

@sergey-tihon the NuGet feed is at https://ci.appveyor.com/nuget/nunit

Currently you need to figure out which build a fix is in by looking at the AppVeyor builds and getting the build number. Less than ideal. We plan to fix it, but haven't yet. Remind me once the PR is merged and I will get you a package version that will work for you.

I assume that the custom formatter will solve your need for the EqualsConstraint and open up more of our constraints for your use. Looking at ChoiceConstraint, it looks like it should just work, although my F# foo is not strong 😄

[rprouse]

@sergey-tihon if you wanted to test with the NuGet package of the current PR, the latest version is 3.1.0-CI-2072

[CharliePoole]

@sergey-tihon Note however that the current PR is marked Do Not Merge because it is still in development. The calling sequence could change.

[sergey-tihon]

Support of NUnit 3 released in FsUnit 2.0.0
Let's tack support of NUnit v3.2 in separate issue - #86