On Sat, Jan 4, 2014 at 12:04 PM, Frank Shearar <frank.shearar at gmail.com>wrote:


>
> It's one of the few things I actually _like_ about Ruby, that RSpec
> has such a nice DSL. I'm not a huge fan of Cucumber (it's possible the
> next few months will either make me hate or love it yet: it's in heavy
> use at my new job), so I'm not talking about a language completely
> different to the host language. It's just that, sometimes, like here,
> I miss Ruby's implicit receivers.
>

Weird. That's the thing I dislike about Ruby. It makes it so easy to play
around with the appearance of code that the Ruby community has become
obsessed with DSLs. It's gotten to the point that libraries and frameworks
are designed more with an eye to a cool DSL than to simplicity or
expressivity or performance.  On the other hand, simply knowing Ruby, the
language, is no longer sufficient to be able to read code and understand
it, you also have to know the semantics of the DSL being used. Since
they're never documented, that means reverse engineering (without a decent
debugger) the weird execution environment they've set up to make the DSL
work, or reading blog posts and mailing lists from the last 3 years to find
an explanation of the DSL.

I much prefer the Smalltalk community's tendency to build layers of
abstraction, while sticking to idiomatic Smalltalk. DSLs have their uses,
but I prefer to see them implemented with a well-defined grammar and a
parser. That gives a lot more syntactic freedom in the design of the DSL
and makes it much easier to understand what's happening at runtime.

Ok, rant over, back to testing.


> But as Colin points out, using something like It is a bit "uncanny
> valley". 'It' is close enough to English that the difference between
> It and English is annoying. I suppose one could have `Assert that: a
> equals: b`.
>

I find the question of syntax for expression of expectations is a
distraction from the real task of testing software. Writing good tests is
*hard*, but the difficulty has little to do with syntax. It's more a
question of factoring the functionality such that testing is simple and
effective, and writing tests that get to the essence of the expected
behaviour, rather than implementation details. If you get that right, the
form the tests take doesn't matter.

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140104/87a33690/attachment.htm