[Pharo-project] Why some packages are rejected from Test Coverage?
Ok, I see that there are some packages that are not able to be selected to run test coverage. I noticed that they were big packages and then I saw the method: TestRunner >> promptForPackages where you can see it rejects packages like Kernel, Collections, System, etc. I guess because Test Coverage may take long time in those big packages....but I don't know if that's a good reason to disable them. Maybe a popup saying "Are you sure you want to run Test Coverage over this package? It will take a lot of time" is better. At least VisualWorks does something similar. What do you think ? Cheers, Mariano
Good idea send code :) After you should pay attention that may be some packages may crash the system when run on coverage I did not try but I imagine that Array, Object and other kernel stuff may suffer. Stef
The rejection of the Kernel, Collections, System is not about the size, it is because of the classes they contain. There are many classes in the system that you can't wrap without possibly harming the system. Especially tricky are classes that are used by the system at all times (so the result would be wrong anyway) and the coverage tools itself (what could result in infinite recursion), such as Process, Context, OrderedCollection, Array, Object, etc. All in all the restrictions imposed on those packages are far too broad, but it was the easiest without testing all classes (which in case of a failure mostly leads to a crash) and without introducing unnecessary dependencies. Lukas 2009/12/2 Mariano Martinez Peck <marianopeck@gmail.com>:
Ok, I see that there are some packages that are not able to be selected to run test coverage. I noticed that they were big packages and then I saw the method:
TestRunner >> promptForPackages
where you can see it rejects packages like Kernel, Collections, System, etc. I guess because Test Coverage may take long time in those big packages....but I don't know if that's a good reason to disable them. Maybe a popup saying "Are you sure you want to run Test Coverage over this package? It will take a lot of time" is better. At least VisualWorks does something similar.
What do you think ?
Cheers,
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
On Wed, Dec 2, 2009 at 10:43 PM, Lukas Renggli <renggli@gmail.com> wrote:
The rejection of the Kernel, Collections, System is not about the size, it is because of the classes they contain. There are many classes in the system that you can't wrap without possibly harming the system. Especially tricky are classes that are used by the system at all times (so the result would be wrong anyway) and the coverage tools itself (what could result in infinite recursion), such as Process, Context, OrderedCollection, Array, Object, etc. All in all the restrictions imposed on those packages are far too broad, but it was the easiest without testing all classes (which in case of a failure mostly leads to a crash) and without introducing unnecessary dependencies.
:( What a pity. I have already coded it :( And there is no way to test coverage only sub categories of a package? Suppose I want to test the category "System-Object Storage" of the package System. Can I do it ? if true, how? Thanks for the explanation.
Lukas
2009/12/2 Mariano Martinez Peck <marianopeck@gmail.com>:
Ok, I see that there are some packages that are not able to be selected to run test coverage. I noticed that they were big packages and then I saw the method:
TestRunner >> promptForPackages
where you can see it rejects packages like Kernel, Collections, System, etc. I guess because Test Coverage may take long time in those big packages....but I don't know if that's a good reason to disable them. Maybe a popup saying "Are you sure you want to run Test Coverage over this package? It will take a lot of time" is better. At least VisualWorks does something similar.
What do you think ?
Cheers,
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
:(  What a pity. I have already coded it :(
And there is no way to test coverage only sub categories of a package? Suppose I want to test the category "System-Object Storage" of the package System. Can I do it ? if true, how?
This is a test runner, not a tool to solve all possible problems. It provides an absolutely minimal implementation of method wrappers that does exactly one thing, and one thing only: calculating coverage on a per-package bases. If you want something more sophisticated you should look at the original implementation of MethodWrappers and their integration in OmniBrowser. Using these two you can conveniently select any set of methods in the image, wrap them with a custom wrapper, perform a custom action, etc. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Dec 2, 2009, at 10:43 PM, Lukas Renggli wrote:
The rejection of the Kernel, Collections, System is not about the size, it is because of the classes they contain. There are many classes in the system that you can't wrap without possibly harming the system. Especially tricky are classes that are used by the system at all times (so the result would be wrong anyway) and the coverage tools itself (what could result in infinite recursion),
hehehe... and people always say research does not solve practical problems: Marcus Denker, Mathieu Suen, and Stéphane Ducasse. The Meta in Meta-object Architectures. In Proceedings of TOOLS EUROPE 2008, LNBIP 11 p. 218â237, Springer-Verlag, 2008 http://scg.unibe.ch/scgbib?query=Denk08b&display=abstract ... sometimes I have the feeling we learned quite a lot the last years. fundamental things, even. I think it will be interesting how the reflective kernel of Pharo will look like in 5 years. Marcus -- Marcus Denker -- http://www.marcusdenker.de
participants (4)
-
Lukas Renggli -
Marcus Denker -
Mariano Martinez Peck -
Stéphane Ducasse