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

[Guillaume Chatelet 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

Google uses gMock. On top of being a mock framework it provides 
composable matchers API which are a great way of expressing what 
you want to test.
https://www.youtube.com/watch?v=sYpCyLI47rM?t=19m15s (excerpt 
from outdated gMock presentation from 2008)

The matcher api is based on Hamcrest and I think it's pretty 
convenient.

Crash or log :
assertThat(...);
expectThat(...);

Simple tests are easy to express.
assertThat(4, 5);

More complex things:
assertThat(theBiscuit, is(equalTo(myBiscuit)));
assertThat(theBiscuit, not(instanceOf(Liquid.class)));

Same thing with container:
assertThat(map, not(hasKey(lessThan(5))));

The tests are pretty readable and predicates compose nicely.

Also because you express the condition as a tree of predicates 
the error reporting can be really nice. Like "map contains 
element which key is not less than 5".

Also one can write custom predicates for more specific tests.
The C++ implementation relies on ugly template/macros. I'm sure a 
D implementation can be cleaner and pretty sweet to use.

I suspect throwing ufcs in here will makes it even better.