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

Frank Shearar frank.shearar at gmail.com
Sat Jan 11 14:14:00 UTC 2014


On 10 January 2014 23:38, Chris Cunningham <cunningham.cb at gmail.com> wrote:
> On Fri, Jan 10, 2014 at 2:39 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>>
>>
>>
>>
>> On Fri, Jan 3, 2014 at 4:14 PM, Colin Putney <colin at wiresong.com> wrote:
>>>
>>>
>>>
>>>
>>> On Fri, Jan 3, 2014 at 3:42 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
>>>>
>>>> > Would it be blasphemy to have a global or class called It? It should:
>>>> > $a equal: $b.
>>>>
>>>> Strangely, I like it.
>>>
>>>
>>> Why? "It should a equal b" isn't a coherent sentence.
>>
>>
>> So
>>
>> So should a equal b ;-)
>>
> maybe
>
> So a should equal b

That, sadly, doesn't work, because here a is a message send to So.
What you need is a message taking a (and b) as parameters, which
requires two words before the word "a". I'm kind've leaning towards
Assert: Assert that: a equals: b.

In RSpec, changing the assertion language means not having to monkey
patch. In our case, TestCase does a whole pile of stuff. One of those
things is a DSL (domain specific vocab, as Colin put it - maybe even
"domain specific jargon") in the form of #assert: and friends. Pulling
that out into (say) Assert means factoring things better. JUnit also
did this, AFAIK, when they pulled in the Hamcrest matchers. (Assert
isn't a novel idea, btw: I've stolen it from NUnit:
Assert.IsTrue(proposition), Assert.AreEqual(a, b).)

frank


More information about the Squeak-dev mailing list