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

>
> On 03.01.2014, at 20:44, Frank Shearar <[hidden email]> wrote:
>
>> On 3 January 2014 19:28, Tobias Pape <[hidden email]> wrote:
>>>
>>> On 03.01.2014, at 20:11, Frank Shearar <[hidden email]> wrote:
>>>
>>>> On 2 January 2014 20:55,  <[hidden email]> 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

>>> 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)…

> On Jan 3, 2014, at 12:36 PM, Frank Shearar <[hidden email]> wrote:
>
>> On 3 January 2014 20:06, Tobias Pape <[hidden email]> wrote:
>>
>>> On 03.01.2014, at 20:44, Frank Shearar <[hidden email]> wrote:
>>>
>>>> On 3 January 2014 19:28, Tobias Pape <[hidden email]> wrote:
>>>>
>>>>> On 03.01.2014, at 20:11, Frank Shearar <[hidden email]> wrote:
>>>>>
>>>>>> On 2 January 2014 20:55,  <[hidden email]> 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
>

>
>
>
> On Fri, Jan 3, 2014 at 3:42 PM, Tobias Pape <[hidden email]> 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.
>
> SUnit doesn't try to make everything into an executable specification (which
> is a good thing), but at least "self assert: a equals: b" reads like fluent
> Smalltalk.

>
>
>
> On Sat, Jan 4, 2014 at 12:04 PM, Frank Shearar <[hidden email]>
> 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.

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

> On Fri, Jan 10, 2014 at 2:39 PM, Eliot Miranda <[hidden email]>
> wrote:
>>
>>
>>
>>
>> On Fri, Jan 3, 2014 at 4:14 PM, Colin Putney <[hidden email]> wrote:
>>>
>>>
>>>
>>>
>>> On Fri, Jan 3, 2014 at 3:42 PM, Tobias Pape <[hidden email]> 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