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