[Cuis-dev] Test error message wrongly formatted
rabbit
rabbit at callistohouse.org
Sat Jul 29 07:17:48 PDT 2023
I grok the root of this discussion is clarity of selector semantic. They ought to state the meaning clearly. Sad SUnit is perceived as set in stone.. isn’t evolution of language important to get smart? I’d would humbly propose new methods: in ProtoObject…
#assertSacrifice: sacrifice equalsJudgement: judgement
#denySacrifice: sacrifice equalsJudgement: judgement
••• rabbit ❤️🔥🐰
On Sat, Jul 29, 2023 at 10:12, rabbit <[rabbit at callistohouse.org](mailto:On Sat, Jul 29, 2023 at 10:12, rabbit <<a href=)> wrote:
> In other words, sacrifice goes before judgement.
>
> <assert: sacrifice equals: judgement”
>
> ••• rabbit ❤️🔥🐰
>
> On Sat, Jul 29, 2023 at 10:05, rabbit via Cuis-dev <[cuis-dev at lists.cuis.st](mailto:On Sat, Jul 29, 2023 at 10:05, rabbit via Cuis-dev <<a href=)> wrote:
>
>> It makes sense to me, though I don’t use it. I use #assert: and parenthesize the argument to explicit code the expectation. However, inside the mind of Kent Beck (was it he who dropped SUnit years ago?), I find I read it as
>>
>> “assert: candidate equals: measuredValue”
>>
>> The jingle defines one’s understanding. If you’re confused, change your jingle. It’s helpful in any situation.
>>
>> Peace,
>> ••• rabbit ❤️🔥🐰
>>
>> On Sat, Jul 29, 2023 at 09:25, Hernán Wilkinson via Cuis-dev <[cuis-dev at lists.cuis.st](mailto:On Sat, Jul 29, 2023 at 09:25, Hernán Wilkinson via Cuis-dev <<a href=)> wrote:
>>
>>> Hi Hilaire,
>>> That it is what I said in my first response of the original thread. People do not know that the first parameter is the expected and I agree that it is not intuitive, but it is keep like that for historical reasons and because a lot of people use it correctly.
>>> The solution is simple: redefine assert:equals: in the test class to do:
>>> assert: actual equals: expected
>>> ^super assert: expected equals: actual
>>>
>>> Cheers!
>>> Hernan
>>>
>>> On Sat, 29 Jul 2023 at 08:31 Hilaire Fernandes <hfern at free.fr> wrote:
>>>
>>>> Hi Hernán,
>>>>
>>>> I understand but the problem is that the users I have observed have the reverse understanding. For example from the packages below:
>>>>
>>>> NeoCSV. ported from Pharo. The more than 50 tests are written with a different understanding. See the expected value is the second parameter:
>>>>
>>>> testEmptyFieldQuoted
>>>> self
>>>> assert: (NeoCSVReader on: '"1",,"3"' readStream) upToEnd
>>>> equals: #(('1' nil '3'))
>>>>
>>>> Locale. package ported from Squeak:
>>>>
>>>> testFromISOString
>>>>
>>>> | locale |
>>>> locale := LocaleID isoString: 'en-us'.
>>>> self
>>>> assert: locale isoLanguage equals: 'en';
>>>> assert: locale isoCountry equals: 'us'
>>>>
>>>> I personally never used assert:equal: before so I don't know about other package using it.
>>>>
>>>> Hilaire
>>>>
>>>> Le 29/07/2023 à 02:05, Hernán Wilkinson a écrit :
>>>>
>>>>> Hi Hilaire,
>>>>> What is happening is correct.
>>>>> I mean, the first parameter has to be the expected object. That it is why it says “Expected …” no matter what the parameter is.
>>>
>>> --
>>>
>>> Hernán Wilkinson
>>> Agile Software Development, Teaching & Coaching
>>> Phone: +54-011-4893-2057
>>> Twitter: @HernanWilkinson
>>> site: [http://www.10Pines.com](http://www.10pines.com/)
>>> Address: Alem 896, Floor 6, Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230729/5327e579/attachment-0001.htm>
More information about the Cuis-dev
mailing list