Let's bikeshed std.experimental.testing assertions/checks/whatchamacallits

[Sebastiaan Koppe via Digitalmars-d]

On Tuesday, 30 June 2015 at 08:06:37 UTC, Atila Neves wrote:
> In case you don't know what I'm talking about: 
> https://github.com/D-Programming-Language/phobos/pull/3207
>
> Since this is an API issue it's import to get it right the 
> first time. Personally I'm not sure what I prefer (well, I am, 
> but what I actually want isn't syntactically valid D). I think 
> the options so far are:
>
> 1) What's there already, namely `shouldEquals`, `shouldBeIn`, 
> etc.
> 2a) Compile-time strings for operators: `should!"=="`, 
> `should!"in"`
> 2b) Dicebot's `test!"=="`. `assert` is so much better, I wish 
> we could use that.
> 3) Composable ones: should.equals, should.not.equals, or 
> another word that isn't "should"
> 4) Anything else?
>
> I'm not convinced composability brings anything to the table 
> except for editor dot-completion. I don't like the verbosity of 
> what's there now, but my prefererred syntax doesn't work except 
> for the ubiquitous  check for equality (`should ==`). Well, the 
> dream would be that `assert(foo == bar)` did what part of this 
> PR does, but that's another story and something that can't be 
> done by a library unless we had AST macros, which we won't. Or 
> Lisp's reader macros, but we won't get those either.
>
> Thoughts? Votes?
>
> Atila


Much rather prefer the composable ones over the `shouldEquals`, 
simply for readability and easy extending.

These days I am leaning towards BDD, but everybody has his 
favorite. Maybe just providing the low-level details in 
std.testing would enough; e.g. a test runner, UDA's and 
assertions.

Then everyone can write his on version of given().when().then() 
on top of it. Or simply make a pull-request for std.testing.bdd