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

On Tuesday, 30 June 2015 at 08:06:37 UTC, Atila Neves wrote:

> 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 ==`).

Could you give some examples of your preferred syntax and why it doesn't work?

On Tuesday, 30 June 2015 at 08:38:44 UTC, Adrian Matoga wrote:
> On Tuesday, 30 June 2015 at 08:06:37 UTC, Atila Neves wrote:
>
>> 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 ==`).
>
> Could you give some examples of your preferred syntax and why it doesn't work?

`foo.should == "bar";` works. Nothing else does (and in fact in retrospect it's surprising that == does) because they do nothing by themselves. `foo.should != bar` is the same as `!(foo == bar)`, which on a statement by itself is nonsensical and rejected by the compiler with "has no effect in expression" error. You could write something like `if(foo.should != "bar") {}` and that compiles fine but it's super hacky and ugly.

Atila

To do it _really_ nice, we would need some sort of ".codeof" feature. Possibly, with implicit returns in lambdas. For example:

void test(alias expr)
{
    if (!expr())
        throw new TestException(
            expr.codeof ~ " has failed,\n" ~
            /* investigate expr context pointer and grab a/b */
            "\ta = x\n" ~
            "\tb = y"
}

unittest
{
    int a, b;
    test!({ a == b; });
}

Of course, this is one of cases where AST macros would really shine. But I think it should be possible to provide necessary functionality subset in a much more simple and limited feature.

In absence of language changes, I don't see anything as clear and simple as operator mixins. Less magic in unittests -> better. Common misconception IMHO is that tests should look nice for library/app author, while, from the ecosystem PoV, they should look simple and predictable for contributors - and that is most important property.

On Tuesday, 30 June 2015 at 08:06:37 UTC, Atila Neves wrote:
> 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?
>
> - snip -
>
> Thoughts? Votes?

I really hate the 3rd persons "s" in "shouldEquals" / "should.equals". Not only is it grammatically wrong, it's also inconsistent with "shouldBeIn", which - following the same scheme - would have to be "shouldIsIn".

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.

On Tuesday, 30 June 2015 at 08:06:37 UTC, Atila Neves wrote:
> 2a) Compile-time strings for operators: `should!"=="`, `should!"in"`
> 2b) Dicebot's `test!"=="`. `assert` is so much better, I wish we could use that.

I think these are both bad, for the reason that ! also means logical not. I read `should!"=="` as "should not equal" before catching myself.

On Tuesday, 30 June 2015 at 11:14:55 UTC, Atila Neves wrote:
> On Tuesday, 30 June 2015 at 08:38:44 UTC, Adrian Matoga wrote:
>> On Tuesday, 30 June 2015 at 08:06:37 UTC, Atila Neves wrote:
>>
>>> 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 ==`).
>>
>> Could you give some examples of your preferred syntax and why it doesn't work?
>
> `foo.should == "bar";` works. Nothing else does (and in fact in retrospect it's surprising that == does) because they do nothing by themselves. `foo.should != bar` is the same as `!(foo == bar)`, which on a statement by itself is nonsensical and rejected by the compiler with "has no effect in expression" error. You could write something like `if(foo.should != "bar") {}` and that compiles fine but it's super hacky and ugly.
>
> Atila

Thanks. I took a second look and now it looks obvious.

I'd vote for Dicebot's bikeshed design (2b). It's short and looks equally readable for every possible test.

Another hackish possibility could be to change the behavior of assert so that it also passes the stringified expression to _d_assert* and _d_unittest* in druntime.

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

On Tuesday, 30 June 2015 at 12:00:36 UTC, Meta wrote:
> On Tuesday, 30 June 2015 at 08:06:37 UTC, Atila Neves wrote:
>> 2a) Compile-time strings for operators: `should!"=="`, `should!"in"`
>> 2b) Dicebot's `test!"=="`. `assert` is so much better, I wish we could use that.
>
> I think these are both bad, for the reason that ! also means logical not. I read `should!"=="` as "should not equal" before catching myself.

I'd forgotten about it, but I knew there was a reason I didn't like `should!"=="`, and it was the same reason as you.

Atila