Re: [Pharo-dev] Weird SUnit/TestRunner behavior

2019-03-20 Thread Attila Magyar
Thanks for the explanation Torsten. I do use setUp for initialization but one exception is BabyMock2TesCase which serves as a base class for other tests. The reason why its variables are created in the init is that the users would likely forget sending a setUp to the super class in their own setUp.

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

2019-03-20 Thread Torsten Bergmann
Attila wrote: >why don't we reinitialize them before running the test? SUnit does - but requires it to be in #setUp. One just has to follow the SUnit framework rules. So if one implements MyTest>>initialize super initialize. s := OrderedCollection new. "note that this is initia

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

2019-03-19 Thread ducasse
Indeed I do not even know what means initialize in a testCase. Stef > On 19 Mar 2019, at 17:28, Max Leske wrote: > > On 19 Mar 2019, at 16:16, Gabriel Cotelli wrote: > >> If you don't clean up the instance variables, when you have a lot of tests >> and a test runner is still open on the resu

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

2019-03-19 Thread Max Leske
On 19 Mar 2019, at 16:16, Gabriel Cotelli wrote: If you don't clean up the instance variables, when you have a lot of tests and a test runner is still open on the results all this garbage is still referenced (because the test results keeps a reference to the original test case instance) and th

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

2019-03-19 Thread Gabriel Cotelli
If you don't clean up the instance variables, when you have a lot of tests and a test runner is still open on the results all this garbage is still referenced (because the test results keeps a reference to the original test case instance) and the image keeps growing like crazy. I can tell you for m

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

2019-03-19 Thread Attila Magyar
Max Leske wrote > To answer your question: yes that has been the case for a long time. The > same is true for #runCase BTW. Only #setUp is sent after #tearDown (see > #prepareToRunAgain). > > Max That's weird. RunCase sends a setUp, a tearDown and cleanUpInstanceVariables. So the test will be e

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

2019-03-18 Thread Max Leske
To answer your question: yes that has been the case for a long time. The same is true for #runCase BTW. Only #setUp is sent after #tearDown (see #prepareToRunAgain). Max On 18 Mar 2019, at 14:05, Attila Magyar wrote: Thanks, I added the ticket. -- Sent from: http://forum.world.st/Pharo-S

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

2019-03-18 Thread Attila Magyar
Thanks, I added the ticket. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

2019-03-18 Thread ducasse
You can add a ticket in DrTests in JulienDelplanque repo on github. https://github.com/juliendelplanque/DrTests Stef > On 18 Mar 2019, at 13:35, Attila Magyar wrote: > > Hi, > > This was originally reported as a BabyMock bug but it looks like it e

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

2019-03-18 Thread ducasse
Thanks for the report. We are working on SUnit improvements. Stef > On 18 Mar 2019, at 13:35, Attila Magyar wrote: > > Hi, > > This was originally reported as a BabyMock bug but it looks like it effects > normal test cases as well. > > Let's say I have a test like this: > > MyTest>>initiali

[Pharo-dev] Weird SUnit/TestRunner behavior

2019-03-18 Thread Attila Magyar
Hi, This was originally reported as a BabyMock bug but it looks like it effects normal test cases as well. Let's say I have a test like this: MyTest>>initialize super initialize. s := OrderedCollection new. "note that this is initialized here not in the setUp as we normally do" MyTest>