Test expectation language (was Re: [squeak-dev] The Inbox: CollectionsTests-dtl.209.mcz)

Frank Shearar frank.shearar at gmail.com
Sun Jan 5 14:05:26 UTC 2014


On 4 January 2014 23:50, Colin Putney <colin at wiresong.com> wrote:
>
>
>
> 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.

Yes. It's not just implicit receivers here, it's also instance_eval
and friends. And "external" DSLs make it clear in what language (hence
what semantics) you're working at any given point.

To be clear, I'm not talking about RSpec's it "should do stuff" {}
syntax. I'm talking about the language used to express assertions.
#assert:equals: is OK (other than it doesn't tell you where you should
put the expected and actual values). It's just not particularly slick.

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

But how can such a reasonable statement lead to endless flame wars, I
ask you? "With sufficient experience, the particular testing syntax
isn't important."

#assert:, #assert:equals: probably aren't ugly enough to warrant
revisiting. It's just... well, they're OK. They're not slick, but as
you point out, writing tests in the first place is much harder than
slickness in the testing syntax.

Oh, one nit with "factoring the functionality such that testing is
simple and effective": I find that by writing my tests first, I don't
need to work hard to make things testable. Or the difficulty in
writing the test in the first place leads to needing to separate the
functionalities in the first place.

frank

> Colin


More information about the Squeak-dev mailing list