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 |
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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |