I tried doing RSpec for Squeak a while back. I don't think it works well. Or I should say: what I tried didn't work well. Your example is pretty close to what I tried:)

I think keeping SUnit as simple as possible in the core system is the best plan. In an external package though, I could see something in the way of an OMeta or PetitParser being applied toward doing spec style tests in Smalltalk. 

Of course don't let me stop you! You might come up with a very nice pure-ST DSL for it yet...

> On Jan 3, 2014, at 12:36 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
> 
>> On 3 January 2014 20:06, Tobias Pape <Das.Linux at gmx.de> wrote:
>> 
>>> On 03.01.2014, at 20:44, Frank Shearar <frank.shearar at gmail.com> wrote:
>>> 
>>>> On 3 January 2014 19:28, Tobias Pape <Das.Linux at gmx.de> wrote:
>>>> 
>>>>> On 03.01.2014, at 20:11, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>>> 
>>>>>> On 2 January 2014 20:55,  <commits at source.squeak.org> wrote:
>>>>>> David T. Lewis uploaded a new version of CollectionsTests to project The Inbox:
>>>>>> http://source.squeak.org/inbox/CollectionsTests-dtl.209.mcz
>>>>>> 
>>>>>> ==================== Summary ====================
>>>>>> 
>>>>>> Name: CollectionsTests-dtl.209
>>>>>> Author: dtl
>>>>>> Time: 2 January 2014, 3:55:41.062 pm
>>>>>> UUID: 5681f129-af93-4f97-9449-b2391be6c8a3
>>>>>> Ancestors: CollectionsTests-fbs.208
>>>>>> 
>>>>>> Provide TextAttributesScanningTest to verify text attribute filein and fileout.
>>>>>> 
>>>>>> Five tests are marked as expected failures. These are tests for text attributes that are apparently unused, and that are likely candidates for removal from the image.
>>>>>> 
>>>>>> There is one failure in a test for PluggableTextAttribute, which is a kind of text attribute that is used by SqueakMap. This is probably a legitimate failure that should be fixed.
>>>>>> 
>>>>>> =============== Diff against CollectionsTests-fbs.208 ===============
>>>>> <snip>
>>>>>> Item was added:
>>>>>> + ----- Method: TextAttributesScanningTest>>testTextAttributeClassFor (in category 'testing') -----
>>>>>> + testTextAttributeClassFor
>>>>>> +       "Verify class identifiers as used in RunArray class>>scanFrom:"
>>>>>> +
>>>>>> +       self assert: (TextAttribute classFor: $a) equals: TextAlignment.
>>>>>> +       self assert: (TextAttribute classFor: $f) equals: TextFontChange.
>>>>>> +       self assert: (TextAttribute classFor: $F) equals: TextFontReference.
>>>>>> +       self assert: (TextAttribute classFor: $b) equals: TextEmphasis.
>>>>>> +       self assert: (TextAttribute classFor: $i) equals: TextEmphasis.
>>>>>> +       self assert: (TextAttribute classFor: $u) equals: TextEmphasis.
>>>>>> +       self assert: (TextAttribute classFor: $=) equals: TextEmphasis.
>>>>>> +       self assert: (TextAttribute classFor: $n) equals: TextEmphasis.
>>>>>> +       self assert: (TextAttribute classFor: $-) equals: TextKern.
>>>>>> +       self assert: (TextAttribute classFor: $+) equals: TextKern.
>>>>>> +       self assert: (TextAttribute classFor: $c) equals: TextColor.
>>>>>> +       self assert: (TextAttribute classFor: $L) equals: TextLink.
>>>>>> +       self assert: (TextAttribute classFor: $R) equals: TextURL.
>>>>>> +       self assert: (TextAttribute classFor: $q) equals: TextSqkPageLink.
>>>>>> +       self assert: (TextAttribute classFor: $p) equals: TextSqkProjectLink.
>>>>>> +       self assert: (TextAttribute classFor: $P) equals: TextPrintIt.
>>>>>> +       self assert: (TextAttribute classFor: $d) equals: TextDoIt.
>>>>> 
>>>>> Yay for #assert:equals:! The expected value goes first, though:
>>>>> otherwise you get a message something like "Expected actualValue but
>>>>> was expectedValue". The same applies, as far as I can see, to the
>>>>> other #assert:equals: calls.
>>>> 
>>>> Which is a  counter-intuitive order for me...
>>>> Is that ansi?
>>> 
>>> It's SUnit. I don't particularly like it, but that's the API.
>>> 
>>> What I'd _really_ like is something like Phexample syntax, which would have
>>> 
>>> (TextAttribute classFor: $d) should = TextDoIt.
>>> 
>>> (Very RSpec-ish. Having said that, RSpec's moved away from should
>>> syntax because it requires monkey patching. So `foo should == :bar` is
>>> now `expect(foo).to eq(:bar)`. Translating that back into Smalltalk
>>> would probably look something like `Expect this: (TextAttribute
>>> classFor: $d) toEqual: TextDoIt`. Ack!)
>> 
>> and there we are again:
>>        `Expect this: (TextAttribute classFor: $d) toEqual: TextDoIt`
>> can easily be:
>>        self assertThat: (TextAttribute classFor: $d) isEqualTo: TextDoIt
>> (which is near self assert: a equals: b, but the other way round again ;)
>> 
>> What about
>> a) instvar named `it' and initialised to self or
>> b) method named #it that returns self (or what the user wants, like an "asserter")
>> and do
>>        it should: (TextAttribute classFor: $d) beEqualTo: TextDoIt
>> or
>>        self it should: (TextAttribute classFor: $d) beEqualTo: TextDoIt
> 
> Would it be blasphemy to have a global or class called It? It should:
> $a equal: $b.
> 
>>>> I like the usage as in the example better..
>>> 
>>> I agree. I just held my nose and adapted. Altering the API means never
>>> being sure that you changed everything, and when you get it wrong you
>>> make someone's life a misery because their debug error message, meant
>>> to _aid_ them, now _lies_ to them.
>> 
>> HmHmmm. But frankly, most people do not look up the argument names and
>> just use it intuitively and they then “think” the system is lying (while
>> it is not)…
> 
> I've burned myself enough times that I just remember that expected goes first.
> 
> frank
> 
>> Best
>>        -Tobias
>