SUnit History

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

SUnit History

Lukas Renggli
I have a few questions to the authors of the SUnit History feature:

1. I noticed is that all the results are stored in a dictionary of
TestResult mapping the classes to their last result. When I delete
tests, these obsolete classes remain references from the dictionary
and thus never get garbage collected. Why not save the history in a
class-instance variable of the TestCase itself? That would even make
the code much simpler.

2. Why to store the history of test results in nested dictionaries,
sets and arrays? We have a nice TestResult object that remembers
exactly the same information and additionally allows to do all kinds
of queryies like #hasFailures, hasPassed, ... I see that there is one
problem here: the current implementation of TestResult remembers the
test case instances, and thus would reference potentially a lot of
unnecessary state. Maybe TestResult should only remember the method
references of the tests, instead of the test cases? I guess that would
solve other problems people regularly report with SUnit as well.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: SUnit History

Lukas Renggli
3. Why the heck is the timestamp of the last run a String :-(

On Wed, Apr 1, 2009 at 12:07 PM, Lukas Renggli <[hidden email]> wrote:

> I have a few questions to the authors of the SUnit History feature:
>
> 1. I noticed is that all the results are stored in a dictionary of
> TestResult mapping the classes to their last result. When I delete
> tests, these obsolete classes remain references from the dictionary
> and thus never get garbage collected. Why not save the history in a
> class-instance variable of the TestCase itself? That would even make
> the code much simpler.
>
> 2. Why to store the history of test results in nested dictionaries,
> sets and arrays? We have a nice TestResult object that remembers
> exactly the same information and additionally allows to do all kinds
> of queryies like #hasFailures, hasPassed, ... I see that there is one
> problem here: the current implementation of TestResult remembers the
> test case instances, and thus would reference potentially a lot of
> unnecessary state. Maybe TestResult should only remember the method
> references of the tests, instead of the test cases? I guess that would
> solve other problems people regularly report with SUnit as well.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>



--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: SUnit History

Alexandre Bergel
In reply to this post by Lukas Renggli
Hi Lukas,

Thanks for your review. We made this in a couple of days.
You suggested some cool changes, indeed.

Cheers,
Alexandre


On 1 Apr 2009, at 12:07, Lukas Renggli wrote:

> I have a few questions to the authors of the SUnit History feature:
>
> 1. I noticed is that all the results are stored in a dictionary of
> TestResult mapping the classes to their last result. When I delete
> tests, these obsolete classes remain references from the dictionary
> and thus never get garbage collected. Why not save the history in a
> class-instance variable of the TestCase itself? That would even make
> the code much simpler.
>
> 2. Why to store the history of test results in nested dictionaries,
> sets and arrays? We have a nice TestResult object that remembers
> exactly the same information and additionally allows to do all kinds
> of queryies like #hasFailures, hasPassed, ... I see that there is one
> problem here: the current implementation of TestResult remembers the
> test case instances, and thus would reference potentially a lot of
> unnecessary state. Maybe TestResult should only remember the method
> references of the tests, instead of the test cases? I guess that would
> solve other problems people regularly report with SUnit as well.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: SUnit History

Stéphane Ducasse
so will you fix it? Alex?


Stef

> Hi Lukas,
>
> Thanks for your review. We made this in a couple of days.
> You suggested some cool changes, indeed.
>
> Cheers,
> Alexandre
>
>
> On 1 Apr 2009, at 12:07, Lukas Renggli wrote:
>
>> I have a few questions to the authors of the SUnit History feature:
>>
>> 1. I noticed is that all the results are stored in a dictionary of
>> TestResult mapping the classes to their last result. When I delete
>> tests, these obsolete classes remain references from the dictionary
>> and thus never get garbage collected. Why not save the history in a
>> class-instance variable of the TestCase itself? That would even make
>> the code much simpler.
>>
>> 2. Why to store the history of test results in nested dictionaries,
>> sets and arrays? We have a nice TestResult object that remembers
>> exactly the same information and additionally allows to do all kinds
>> of queryies like #hasFailures, hasPassed, ... I see that there is one
>> problem here: the current implementation of TestResult remembers the
>> test case instances, and thus would reference potentially a lot of
>> unnecessary state. Maybe TestResult should only remember the method
>> references of the tests, instead of the test cases? I guess that  
>> would
>> solve other problems people regularly report with SUnit as well.
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: SUnit History

Alexandre Bergel
yes, I will fix this

Alexandre


On 1 Apr 2009, at 19:39, Stéphane Ducasse wrote:

> so will you fix it? Alex?
>
>
> Stef
>
>> Hi Lukas,
>>
>> Thanks for your review. We made this in a couple of days.
>> You suggested some cool changes, indeed.
>>
>> Cheers,
>> Alexandre
>>
>>
>> On 1 Apr 2009, at 12:07, Lukas Renggli wrote:
>>
>>> I have a few questions to the authors of the SUnit History feature:
>>>
>>> 1. I noticed is that all the results are stored in a dictionary of
>>> TestResult mapping the classes to their last result. When I delete
>>> tests, these obsolete classes remain references from the dictionary
>>> and thus never get garbage collected. Why not save the history in a
>>> class-instance variable of the TestCase itself? That would even make
>>> the code much simpler.
>>>
>>> 2. Why to store the history of test results in nested dictionaries,
>>> sets and arrays? We have a nice TestResult object that remembers
>>> exactly the same information and additionally allows to do all kinds
>>> of queryies like #hasFailures, hasPassed, ... I see that there is  
>>> one
>>> problem here: the current implementation of TestResult remembers the
>>> test case instances, and thus would reference potentially a lot of
>>> unnecessary state. Maybe TestResult should only remember the method
>>> references of the tests, instead of the test cases? I guess that
>>> would
>>> solve other problems people regularly report with SUnit as well.
>>>
>>> Lukas
>>>
>>> --
>>> Lukas Renggli
>>> http://www.lukas-renggli.ch
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: SUnit History

Alexandre Bergel-4
In reply to this post by Lukas Renggli
> 3. Why the heck is the timestamp of the last run a String :-(

Even the timestamp is not used currently, it should not be stored as a  
String

Alexandre

>
> On Wed, Apr 1, 2009 at 12:07 PM, Lukas Renggli <[hidden email]>  
> wrote:
>> I have a few questions to the authors of the SUnit History feature:
>>
>> 1. I noticed is that all the results are stored in a dictionary of
>> TestResult mapping the classes to their last result. When I delete
>> tests, these obsolete classes remain references from the dictionary
>> and thus never get garbage collected. Why not save the history in a
>> class-instance variable of the TestCase itself? That would even make
>> the code much simpler.
>>
>> 2. Why to store the history of test results in nested dictionaries,
>> sets and arrays? We have a nice TestResult object that remembers
>> exactly the same information and additionally allows to do all kinds
>> of queryies like #hasFailures, hasPassed, ... I see that there is one
>> problem here: the current implementation of TestResult remembers the
>> test case instances, and thus would reference potentially a lot of
>> unnecessary state. Maybe TestResult should only remember the method
>> references of the tests, instead of the test cases? I guess that  
>> would
>> solve other problems people regularly report with SUnit as well.
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>>
>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: SUnit History

Alexandre Bergel-4
In reply to this post by Lukas Renggli
> 1. I noticed is that all the results are stored in a dictionary of
> TestResult mapping the classes to their last result. When I delete
> tests, these obsolete classes remain references from the dictionary
> and thus never get garbage collected. Why not save the history in a
> class-instance variable of the TestCase itself? That would even make
> the code much simpler.

Good point indeed.
ISSUE 711.
SUnit-Alexandre_Bergel.62.mcz in PharoInbox


> 2. Why to store the history of test results in nested dictionaries,
> sets and arrays? We have a nice TestResult object that remembers
> exactly the same information and additionally allows to do all kinds
> of queryies like #hasFailures, hasPassed, ... I see that there is one
> problem here: the current implementation of TestResult remembers the
> test case instances, and thus would reference potentially a lot of
> unnecessary state. Maybe TestResult should only remember the method
> references of the tests, instead of the test cases? I guess that would
> solve other problems people regularly report with SUnit as well.

We did this because an history does not contains the last run for the  
class. You could run all the tests for a class, subsequently run just  
one test. The history associated to this class should not contains the  
last run, but a combination of the both. Having a method  
TestResult>>merge: would help. I will work on that soon.

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project