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

[Jacob Carlborg via Digitalmars-d]

On 01/07/15 10:40, Atila Neves wrote:

> So, despite the fact that I wrote `shouldBeGreaterThan`, I hate its
> verbosity

You could write "shouldBe.gt(value)".

> I don't buy that `should.` is more extensible. For two reasons, first
> because in all the test frameworks I've seen there aren't that many more
> types of assertions

In every project I have used RSpec I have added custom 
matchers/assertions. Just a couple of days ago I added a custom matcher 
to one of my projects:

code = code_to_file('void foo() {}')
code.should be_parsed_as('meta.definition.method.d')

The point of these custom matchers/assertions are that they should make 
the tests (or specs in the BDD case) more readable and provide better 
assertion failure messages. Of course, none of these assertions are 
necessary, we could all just use "assert" or "shouldEqual", in the end 
every assertion is just a boolean condition.

My test could instead look like this, without using a custom matcher:

file = code_to_file('void foo() {}')
result = `spec/bin/gtm < "#{file.path}" Syntaxes/D.tmLanguage 2>&1`
line = result.split("\n").first
scope = 'meta.definition.method.d'
assert line =~ /#{Regexp.escape(scope)}/

Which one of the two versions are more readable?

> and secondly because adding a member function to
> the struct returned by `should` and adding a new `shouldCamelCase`
> function is the same amount of work.

The idea would be that the part after "should" would be a free function 
and use UFCS to call it.

Should should()
{
     return Should();
}

void beCamelCase(Should s);

should.beCamelCase

That's what allows to create custom assertions. A user of the library 
can't extend the struct returned by "should".

-- 
/Jacob Carlborg