Smalltalk › Pharo › Pharo Smalltalk Developers

Why some packages are rejected from Test Coverage?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Mariano Martinez Peck

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

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

Stéphane Ducasse

Re: Why some packages are rejected from Test Coverage?

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

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

Lukas Renggli

Re: Why some packages are rejected from Test Coverage?

In reply to this post by Mariano Martinez Peck

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 <[hidden email]>:

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

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

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

Mariano Martinez Peck

Re: Why some packages are rejected from Test Coverage?

On Wed, Dec 2, 2009 at 10:43 PM, Lukas Renggli <[hidden email]> 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 <[hidden email]>:

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

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

_______________________________________________
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

Marcus Denker-3

Re: Why some packages are rejected from Test Coverage?

In reply to this post by Lukas Renggli

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

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

Lukas Renggli

Re: Why some packages are rejected from Test Coverage?

In reply to this post by Mariano Martinez Peck

> :( 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

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