[squeak-dev] assert:equals: in Object

Eliot Miranda eliot.miranda at gmail.com
Tue Oct 27 14:19:32 UTC 2020


Hi Hannes,

> On Oct 26, 2020, at 2:46 PM, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> 
> Hi Tim
> 
> Not fully sure what you mean, probably not
>     cod (a type of fish)
>     cod (cash on delivery)
>     doc (the extension of an MS Word file which these days might
> often be larger than a Squeak image)
> 
> :-)
> 
> 
> a) As for the original proposal from Eliot which started this thread,
> what is your conclusion?
> and / or related to this
> 
> 
> My impression is that Eliot's main concern is a smooth workflow in
> moving code back and forth from an SUnit test to a workspace. As this
> discussion shows this may also be adressed on the workspace level.
> 
> 
> But for the moment he says that adding one method to class Object would help him

My response earlier in got lost.  I realized that the issue is my own incompetence.  Instead if using a regular workspace one can use an inspector on the test case itself.  

I suppose the nice extension would be to allow one to define a default receiver for a Workspace other than nil.  This is simply a UI convenience; there is less visual noise in using a workspace than an inspector.  Conceptually alongside the allow automatic variable declaration/reset workspace variables menu items one could have a “specify default receiver via doit...” entry and store the default receiver in the variables dictionary.  Resetting variables would have the side effect of resetting the default receiver back to nil.

But it isn’t a big deal.  What I should do is try and get it into my head that I can always run doits in an inspector if I want to get at a specific class’s protocol.

_,,,^..^,,,_ (phone)

> 
> --Hannes
> 
> 
> Details:
> ----------
> 
> A Squeak 5.3 release image has out of the box
> 
> Object subclass: #TestCase
>    instanceVariableNames: 'testSelector timeout'
>    classVariableNames: ''
>    poolDictionaries: ''
>    category: 'SUnit-Kernel'
> 
> 
> 
> assert: aBooleanOrBlock
> 
>    aBooleanOrBlock value ifFalse: [self signalFailure: 'Assertion failed']    
>    
> 
>    
> assert: aBooleanOrBlock description: aStringOrBlock
> 
>    aBooleanOrBlock value ifFalse: [
>        | description |
>        description := aStringOrBlock value.
>        self logFailure: description.
>        TestResult failure signal: description ]
>    
>    
> 
> assert: expected equals: actual
> 
>    ^self
>        assert: expected = actual
>        description: [ self comparingStringBetween: expected and: actual ]    
> 
> 
> assert: expected equals: actual description: aString
> 
>    ^self
>        assert: expected = actual
>        description: [ aString , ': ', (self comparingStringBetween:
> expected and: actual) ]
>    
> 
>        
> Meanwhile class Object has
> 
> assert: aBlock
>    "Throw an assertion error if aBlock does not evaluates to true."
> 
>    aBlock value ifFalse: [AssertionFailure signal: 'Assertion failed']
> 
> 
> assert: aBlock description: aStringOrBlock
>    "Throw an assertion error if aBlock does not evaluates to true."
> 
>    aBlock value ifFalse: [ AssertionFailure signal: aStringOrBlock value ]
> 
> 
> assert: aBlock descriptionBlock: descriptionBlock
>    "Throw an assertion error if aBlock does not evaluate to true."
> 
>    aBlock value ifFalse: [AssertionFailure signal: descriptionBlock
> value asString ]
>    
>    
> but no
>        
> 
> assert: expected equals: actual
> 
> 
> And this is the main request by Eliot: to have this method
> 
> assert: expected equals: actual
> 
> 
> also in class object as I understand it.
> 
> As for me -- no objection to that.
> 
> 
>> On 10/26/20, tim Rowledge <tim at rowledge.org> wrote:
>> 
>> 
>>>> On 2020-10-25, at 11:40 PM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
>>> 
>>>> A situation where SUnit and all the tests are not necessarily loaded.
>>> 
>>> Hmm... maybe we might consider adding an SUnit-Core? Well, not sure it
>>> makes sense to have an image without SUnit. But then you might want to
>>> also strip, e.g., network support to shrink the image file a little bit
>>> more. :-)
>> 
>> Once upon a time that was a big deal because memory was short. Given that I
>> have been sent almost content-free Word documents that take up more space
>> than a well loaded Squeak image, I suggest we probably don't need to care so
>> much these days.
>> 
>> It offends my CDO (OCD but the letters in *the right order*), but that's the
>> reality.
>> 
>> 
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> It said, "Insert disk #3," but only two will fit!
>> 
>> 
>> 
>> 
> 


More information about the Squeak-dev mailing list