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

[Dicebot via Digitalmars-d]

On Wednesday, 1 July 2015 at 19:38:20 UTC, Jacob Carlborg wrote:
> 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?

Neither. But with the second one I at least have a chance to 
figure out what it actually tests. To understand the first one 
I'd need to read the code of that custom matcher.

This is exactly the problem with all that fancy - library/app 
author (who by definition knows the domain well) implicitly 
introduces custom DSL and expects everyone (who, by definition, 
have very vague understanding of domain) to be able to read it as 
comfortably as himself.