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 <[email protected]>: > 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
