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.
