Decouple assertions and tests

Hi

Sorry to be writing like this out of the blue, but I’d been working on an F#-based test runner similar to Expecto for a while, and never really gotten anywhere with it, and then I ran into Expecto. It seems to be doing pretty much what I’d like an automated testing library to do. The fact that I never really got anywhere with my own project, while this is now almost at version 5, I can only interpret as an indication that you’re better F# programmers than I am 👍

I’d like to help promulgating the message of tests as first-class values, and also, perhaps, if time allows, help with a bit of code now and then. Perhaps even some documentation 😄 (FWIW, as an example, I’ve written a decent bit of FsCheck’s Generating test data page).

There is, however, one major blocker for me in the current Expecto library. You may think that this is terribly irrational of me, but I dislike the fact that Expecto includes an assertion library (the Expect module). Tests and assertions are two separate concerns.

xUnit.net split off their assertion library in version 2.0 for this reason. This is one of several reasons I currently prefer xUnit.net over other libraries; I get to choose an assertion library of my own choice (Unquote).

If Expecto would decouple assertions from tests, this could tip the scale for me, making me prefer Expecto over xUnit.net.

It could be done in the same way that xUnit.net does it: the Expecto package could remain as it is now, but underneath, it would consist of two dependent packages, Expecto.Assertion and Expecto.Test, or something to that effect. Thus, it might not even need to be a breaking change.

One counter-argument that I can already predict is: can’t you use Expecto and simply ignore the Expect module? Yes, I can do that if I’m working by myself, but if I’m in a team, then I’d need to explain to other team members why they should use e.g. Unquote instead of the built-in module, and I’d need to constantly police the code base to ensure that assertions are written according to policy. That’s a problem I don’t think I ought to have.

If my suggestion of creating two separate libraries is welcome, I don’t mind sending a pull request, but I’d like to ask before I do any work.

[AnthonyLloyd]

@ploeh No worries. I’ll keep this open and add help wanted. Hopefully we can simplify to just netcore and VS tooling gets there soon.

[ploeh]

OK, I give up on this. It’s not your fault, but I spent most of yesterday fighting with all sorts of build errors. Either I have no idea what I’m doing, or the combination of F#, .NET Core, and VS 2017 is still too immature.

Anyways, I don’t feel like starting over.

If you rely on me to address this issue, you can close it.

Sorry 😟