[SUnit] how to: clean up *all* obsolete classes during tests?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[SUnit] how to: clean up *all* obsolete classes during tests?

Max Leske
I have I case where I absolutely need to get rid of all obsolete classes but #fixObsoleteReferences simply refuses to nuke all entries in the #ObsoleteSubclasses variable of Behavior. The classes and meta classes that don't go away are subclasses of ClassFactoryForTestCase and I do send it the #cleanup method.

I noticed that this only is true as long as the test runner is open. Once I close the test runner, #fixObsoleteReferences succeeds. But that doesn't really help me because my test case fails *in* the test runner of course…

Here's a test case that illustrates my problem:

ClassFactoryForTestCaseTest>>testObsoleteReferences
        factory delete: factory new class.
        factory cleanUp.
        self
                shouldnt: [ Smalltalk fixObsoleteReferences ]
                raise: Error

Image: 4.4
Build: #12320
VM: SqueakVM 4.2.5.bea1U

Cheers,
Max
Reply | Threaded
Open this post in threaded view
|

Re: [SUnit] how to: clean up *all* obsolete classes during tests?

Frank Shearar-3
On 26 February 2013 23:32, Max Leske <[hidden email]> wrote:
> I have I case where I absolutely need to get rid of all obsolete classes but #fixObsoleteReferences simply refuses to nuke all entries in the #ObsoleteSubclasses variable of Behavior. The classes and meta classes that don't go away are subclasses of ClassFactoryForTestCase and I do send it the #cleanup method.
>
> I noticed that this only is true as long as the test runner is open. Once I close the test runner, #fixObsoleteReferences succeeds. But that doesn't really help me because my test case fails *in* the test runner of course…

The TestRunner keeps a handle on the obsolete classes. I don't know
enough about SUnit to know the precise fix, but it seems like
#fixObsoleteReferences could walk - like it does for Preferences -
_something_ (TestSuites? TestCases?) and manually repair the
references?

Nicolas, thoughts? (I'm picking on you just because you touched
#fixObsoleteReferences last, and therefore know more than me :) )

frank

Reply | Threaded
Open this post in threaded view
|

Re: [SUnit] how to: clean up *all* obsolete classes during tests?

Max Leske
Thanks Frank.

I tried again (more awake) and I was able to solve the problem. In Pharo, the TestSuite has a mechanism to nuke all the instance vars of the test classes during tearDown. That's the reason why this cropped up in Squeak. The solution was to write our own little helper for that:

tearDownInstanceVariables
        self class withAllSuperclasses do: [ :class |
                class = TestCase ifTrue: [ ^ self ].
               
                class instVarNames do: [ :varName |
                        self
                                instVarNamed: varName
                                put: nil ] ]

Cheers,
Max


On 27.02.2013, at 11:33, Frank Shearar <[hidden email]> wrote:

> On 26 February 2013 23:32, Max Leske <[hidden email]> wrote:
>> I have I case where I absolutely need to get rid of all obsolete classes but #fixObsoleteReferences simply refuses to nuke all entries in the #ObsoleteSubclasses variable of Behavior. The classes and meta classes that don't go away are subclasses of ClassFactoryForTestCase and I do send it the #cleanup method.
>>
>> I noticed that this only is true as long as the test runner is open. Once I close the test runner, #fixObsoleteReferences succeeds. But that doesn't really help me because my test case fails *in* the test runner of course…
>
> The TestRunner keeps a handle on the obsolete classes. I don't know
> enough about SUnit to know the precise fix, but it seems like
> #fixObsoleteReferences could walk - like it does for Preferences -
> _something_ (TestSuites? TestCases?) and manually repair the
> references?
>
> Nicolas, thoughts? (I'm picking on you just because you touched
> #fixObsoleteReferences last, and therefore know more than me :) )
>
> frank
>