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

[Sebastiaan Koppe via Digitalmars-d]

On Thursday, 2 July 2015 at 12:28:41 UTC, Dicebot wrote:
> 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.

The good thing about the first one is that you give it a name. 
The names tells you something about what it does, without having 
to understand the low-level details - but also, it gives you 
something to refer to in the documentation.

Moreover, it is the inevitable outcome after one has 
copy-and-pasted the second version 10 times.

> 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.

A natural consequence of having a domain in the first place.