Remove doubled exception message from nunit

[CaptnCodr]

As mentioned here: #166 (comment)

[CaptnCodr]

I'm not quite lucky about the Environment.NewLine Environment.NewLine.
@sergey-tihon Do you have an idea to make it prettier?

[sergey-tihon]

I am not sure about...

type InitMsgUtils() =
     inherit FSharpCustomMessageFormatter()

I (somehow) missed this line in docs for years and I think that I am not along here.
It is quite not intuitive ... it would be much easier to just reference FsUnit and use operators.

Can we remove FSharpCustomMessageFormatter from docs and continue use your implementation?
will it fix double error message?

[CaptnCodr]

Yes, I agree.

I will overthink this approach to have a neat implementation that nobody have to add this piece of code to their implementation. It's not quite intuitive.

Now: When we remove FSharpCustomMessageFormatter then assertion messages will print "ugly" in some cases. No doubled assertion output.

Goal: Removing FSharpCustomMessageFormatter and pretty printed messages.

I go for it.

[CaptnCodr]

It now works, @sergey-tihon.

I removed type InitMsgUtils() = inherit FSharpCustomMessageFormatter() from tests and added an instantiation to the shouldEqual and shouldNotEqual functions.

• The user not have to add type InitMsgUtils() = inherit FSharpCustomMessageFormatter() to their code.
• It pretty prints the special types and no double assertion messages.
• It prints the native NUnit messages ("Expected: ... But was: ...").

Edit: We could remove FSharpCustomMessageFormatter from the docs but it's still supported from our side though it's not necessary anymore. What do you think?

[sergey-tihon]

https://docs.nunit.org/articles/nunit/writing-tests/attributes/setupfixture.html

The OneTimeSetUp method in a SetUpFixture is executed once before any of the fixtures contained in its namespace.

FSharpCustomMessageFormatter affects only tests from the same namespace 😢

A SetUpFixture outside of any namespace provides SetUp and TearDown for the entire assembly.

It should be defined in global namespace to affect whole assembly 😢

Looks like there is no better way to add custom formatter to NUnit rather than SetUpFixture in global namespace

[CaptnCodr]

Do we another chance leave it like it is? or do you have another plan?

FSharpCustomMessageFormatter affects only tests from the same namespace 😢

And FSharpCustomMessageFormatter have to be initialized to work properly - in our code or in the user's code.

[sergey-tihon]

Do we another chance leave it like it is? or do you have another plan?

I think that we can merge this PR as it is and improve FsUnit docs with information that FSharpCustomMessageFormatter is required, why and how to use it.

And FSharpCustomMessageFormatter have to be initialized to work properly - in our code or in the user's code.

We cannot cover all cases from out code =( because user can directly can NUnit functions without FsUnit operators.

[CaptnCodr]

I think there are two ways to use it:
-> Implement type InitMsgUtils() = inherit FSharpCustomMessageFormatter() as before in the assembly where is it required.
or
-> Initialize FSharpCustomMessageFormatter() where this is needed e.g. when the Result-Type is to be used.

We could add the docs changes in this PR, couldn't we?!

[sergey-tihon]

We could add the docs changes in this PR, couldn't we?!

yes, sure

-> Initialize FSharpCustomMessageFormatter() where this is needed e.g. when the Result-Type is to be used.

I do not see an easy way to do this ...

[CaptnCodr]

I will test some things later this day.

[CaptnCodr]

@sergey-tihon Do we still need the init.fs?
Do we have tests that they have "ugly" print? 😄

We could also have implemented both, the init.fs with the global namespace and initialization from [<SetUp>]?!

[CaptnCodr]

Do we have tests that they have "ugly" print?

The best way to test this is to implement tests for each operator. 😅

I do not see an easy way to do this ...

... from [<SetUp>].

[sergey-tihon]

Do we still need the init.fs?

Yes, at least your new Assert.Throws<AssertionException> tests

The best way to test this is to implement tests for each operator. 😅

Yes, awesome idea ;)

... from [].

Inside each test fixture? can you show sample?

[CaptnCodr]

Yes, at least your new Assert.Throws tests

We only need this when we have the special types.

Yes, awesome idea ;)

I will start a marathon shortly to implement this. But first let us merge this PR. ;)

Inside each test fixture? can you show sample?

When it's needed then the user can add it like here:
https://github.com/fsprojects/FsUnit/pull/167/files#diff-574f44828900600e2662b43a782f3efcR28-R30

I adjusted the doc to that effect:
https://github.com/fsprojects/FsUnit/pull/167/files#diff-a60cf0d77453ee3950367857e2bf74d4R35-R49

[CaptnCodr]

Do we have tests that they have "ugly" print?

Every operator in FsUnit.NUnit is affected to have ugly printing but putting type InitMsgUtils() = inherit FSharpCustomMessageFormatter() to init.fs in namespace global is the best way to have this for all tests.

For single tests the user can add [<SetUp>] member __.setup () = FSharpCustomMessageFormatter() |> ignore to the TestFixture or FSharpCustomMessageFormatter() |> ignore in one test.

I see the effort that is too high to the test all operators. We have no chance to take the work from the user.

We could try to resolve this with nunit/nunit (or is dotnet/fsharp the right way?) to have a effortless integration.
@sergey-tihon Do you want to open an issue for that?

I could remove [<SetUp>] member __.setup () = FSharpCustomMessageFormatter() |> ignore from this PR to stay clean. I'm a bit disappointed about this behaviour and that we can not fix this on our side.

[CaptnCodr]

When somebody is testing his/her F# project within a C#-Project an Result-Type it's appearing there too like this:

This is from a C# NUnit project with following code:

var ok = FSharpResult<string, string>.NewOk("ok");
var nook = FSharpResult<string, string>.NewOk("not ok");
Assert.AreEqual(ok, nook);

Edit: Ah, never mind. It works with following C# code:

var ok = FSharpResult<string, string>.NewOk("ok");
var nook = FSharpResult<string, string>.NewOk("not ok");
Assert.AreEqual(ok.ResultValue, nook.ResultValue);

[CaptnCodr]

@sergey-tihon or I implement a special operator that handles the Result-Type (shouldEqualResult or equalResult) on our side. 🤣
What do you think?

That could look like:
Ok "ok" |> shouldEqualResult Ok "ok" or
Ok "ok" |> should equalResult (Ok "ok")

(Sorry, for the mass of comments and mentions.)

[sergey-tihon]

I've removed setup methods from our tests, because I do not understand why we need them together with init.fs

Why do we need shouldEqualResult? Does not it covered by FSharpCustomMessageFormatter? We cannot operator for every F# specific type (Result from FSharp.Core, Result from Chessie and etc)

[CaptnCodr]

Yes, I see.
We cannot implement everything for every purpose.