Why does the 3.0 test library depend on XUnit.Assert?

[RxDave]

I'm using MS Test in my projects and I'd rather not have any dependencies on XUnit. Is there any chance that you'll drop this dependency? Why include it in the first place given that the 2.2.5 release worked just fine without it?

[clairernovotny]

This was done during the port to .NET Core as there was no .NET Core support for MSTest at the time. The 2.2.5 version did have a dependency on MSTest's assertions.

The assertions are an implementation detail of ReactiveAssert, but we can look into using a source version and making it internal. Would that work for you?

[RxDave]

Thanks for the answer! I didn't realize that there was a dependency on MSTest. I'd agree that, if possible, the Rx library should be test library-agnostic.

I think that Debug.Assert typically works with any test framework. Would you consider using that instead?

[clairernovotny]

Debug.Assert doesn't really work for a couple of reasons:

1. It's conditionally-compiled for DEBUG, so in our release builds of the library it'd be a no-op.
2. Even if we were to #define DEBUG in the file to get around that, Debug.Assert throws up a modal dialog. What we need is an exception that gets translated into a test failure.
3. What we really need are things like Assert.Same, Assert.SequenceEqual, etc. No good reason for us to reimplement that logic when there are existing assertion libraries that already do that.

Using a source-version of the assertions should address this though to remove the external dependency, right?

[RxDave]

Point taken about conditional compilation, and actually Debug.Assert does show a modal dialog, which I just verified. I really thought that MSTest and NUnit intercepted it to simply fail the test (never used XUnit). Not sure why I thought that, but I guess I was wrong.

Embedding parts of the source is of course fine too, and it would prevent having to build custom assertion methods, but I was just thinking that the Rx test framework probably doesn't need any dependencies on semantic assertion methods in the first place. It defines its own semantic assertions, via ReactiveAssert, thus it should be able to use some kind of standard assertion mechanism internally to alert any test runner that there is a failure; e.g., a simple test-framework agnostic Assert.Fail mechanism should technically be good enough to implement ReactiveAssert. Or am I missing something?

Anyway, that's perhaps a limitation in the FCL. It would be great to have a general-purpose Test.Assert method or something like that. Barring that, we're in agreement.

[RxDave]

Maybe it's overkill, but I could imagine another platform-enlightenment package that injects the core of ReactiveAssert based on the target test Framework?

[clairernovotny]

Cool...yeah, I think a platform enlightenment is a bit overkill here, especially as we're aiming to consolidate the packages into fewer ones that are cross-compiled (no loss of features, just fewer packages) in #199.

In the end, it doesn't really matter what type of exception is thrown as all test frameworks will fail a test that has an unhandled exception.

[RxDave]

Another good point. Maybe a ReactiveAssertException is the easiest solution.
Edit: Well, unless you have a test that expects an exception to be thrown...

[clairernovotny]

Waiting on this to be merged in and we'll be good to go:
xunit/assert.xunit#4