Replacing nUnit with xUnit and parallelizing tests where possible.

[stebet]

Proposed Changes

Replacing nUnit with xUnit since xUnit is more widely used, has built-in code analyzers and has better parallelization options. Also fixed code in the main project that starts failing after updating Visual Studio to v16.9.

Types of Changes

• Bug fix (non-breaking change which fixes issue #NNNN)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause an observable behavior change in existing systems)
• Documentation improvements (corrections, new content, etc)
• Cosmetic change (whitespace, formatting, etc)

Checklist

• I have read the CONTRIBUTING.md document
• I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
• All tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in related repositories

[michaelklishin]

I see a fair amount of these warnings when I ./run-test.sh on .NET Core 3.1 on macOS:

[xUnit.net 00:01:50.38]     RabbitMQ.Client.Unit.TestConnectionRecovery.TestRecoveryWithTopologyDisabled [FAIL]
[xUnit.net 00:01:50.38]       Microsoft.VisualStudio.TestPlatform.TestHost.DebugAssertException : Method <method> failed with 'columns[1] is not in expected format.
[xUnit.net 00:01:50.38]       ', and was translated to Microsoft.VisualStudio.TestPlatform.TestHost.DebugAssertException to avoid terminating the process hosting the test.
  Failed RabbitMQ.Client.Unit.TestConnectionRecovery.TestRecoveryWithTopologyDisabled [446 ms]
  Error Message:
   Microsoft.VisualStudio.TestPlatform.TestHost.DebugAssertException : Method <method> failed with 'columns[1] is not in expected format.
', and was translated to Microsoft.VisualStudio.TestPlatform.TestHost.DebugAssertException to avoid terminating the process hosting the test.

[michaelklishin]

Never mind, this has to do with me running against a RabbitMQ node build from a development PR. In other words, rabbitmqctl output and not this test. Trying with 3.8.14 now.

[michaelklishin]

Nope, the error is also present with 3.8.14 and has to do with how RabbitMQCtl.ListConnections parses the output. Comparing with master next.

[michaelklishin]

./build.sh; dotnet test projects/Unit -f netcoreapp3.1 --filter "FullyQualifiedName~RabbitMQ.Client.Unit.TestConnectionRecovery"

passes on both branches. Trying to reproduce on two separate machines now.

[michaelklishin]

For some reason

export RABBITMQ_RABBITMQCTL_PATH=rabbitmqctl; dotnet test projects/Unit; ./run-test.sh

against a 3.8.14 node passes (twice) in master but not on this branch. Something affects
how

rabbitmqctl list_connections -s pid client_properties

output is parsed.

[michaelklishin]

Curiously, running the connection recovery test suite alone executed like this:

RABBITMQ_RABBITMQCTL_PATH=rabbitmqctl dotnet test projects/Unit --filter "FullyQualifiedName~RabbitMQ.Client.Unit.TestConnectionRecovery"

passes on this branch.

[stebet]

Interesting. I'll take a look.

[stebet]

Made a change to how the names are parsed to try and fix things @michaelklishin.

[michaelklishin]

That helped, thank you.