[Pharo-project] run all tests from superClass
A change have been saved in 'PharoInBox' for class TestCase in package SUnit so that suite are now built from allSelectors. This makes sense when you have testcase classes which inherits from each other and have parametrized (hook-based) setup.
HI guys I was coding this afternoon with Cyrille who is working a lot to improve the test coverage of collections. And we found a bit strange that when a testcase inherits from another one the tests of the superclass are not run. I checked a bit SUnit code and superclass testmethods are only run is the superclass is abstract or if there are not testmethods. Imagine BagTest IdentityBagTest We could redefine buildSuite on BagTest to invoke allSelectors but this means in essence that we could do it on a lot of potential testcase classes that may be subclasses. Or we could redefine buildSuite on IdentyBagTest but this means that the subclasses should specify it. May be this solution is the best but I wanted to get your thoughts. Of course this idea of inheriting test case make sense when superclass setup can be reused in subclasses one. So the default behavior of buildSuite always invoking all testmethods may not be so good but then via subclassing from BagTest if this is not to reuse it. Stef On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote:
A change have been saved in 'PharoInBox' for class TestCase in package SUnit so that suite are now built from allSelectors. This makes sense when you have testcase classes which inherits from each other and have parametrized (hook-based) setup.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Maybe add a switch runSuperTests "Tells whether test from superclass should be run. By default, this is true. If you don't want to run superclass tests, redefine this as false in your subclass." ^true 2009/4/29 Stéphane Ducasse <stephane.ducasse@inria.fr>:
HI guys
I was coding this afternoon with Cyrille who is working a lot to improve the test coverage of collections. And we found a bit strange that when a testcase inherits from another one the tests of the superclass are not run. I checked a bit SUnit code and superclass testmethods are only run is the superclass is abstract or if there are not testmethods. Imagine BagTest IdentityBagTest
We could redefine buildSuite on BagTest to invoke allSelectors but this means in essence that we could do it on a lot of potential testcase classes that may be subclasses.
Or we could redefine buildSuite on IdentyBagTest but this means that the subclasses should specify it. May be this solution is the best but I wanted to get your thoughts.
Of course this idea of inheriting test case make sense when superclass setup can be reused in subclasses one. So the default behavior of buildSuite always invoking all testmethods may not be so good but then via subclassing from BagTest if this is not to reuse it.
Stef
On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote:
A change have been saved in 'PharoInBox' for class TestCase in package SUnit so that suite are now built from allSelectors. This makes sense when you have testcase classes which inherits from each other and have parametrized (hook-based) setup.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
There is already such a switch that can be overridden in TestCase class>>#shouldInheritSelectors. Lukas On Wed, Apr 29, 2009 at 10:03 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Maybe add a switch runSuperTests   "Tells whether test from superclass should be run.   By default, this is true.   If you don't want to run superclass tests, redefine this as false in your subclass."
  ^true
2009/4/29 Stéphane Ducasse <stephane.ducasse@inria.fr>:
HI guys
I was coding this afternoon with Cyrille who is working a lot to improve the test coverage of collections. And we found a bit strange that when a testcase inherits from another one the tests of the superclass are not run. I checked a bit SUnit code and superclass testmethods are only run is the superclass is abstract or if there are not testmethods. Imagine     BagTest         IdentityBagTest
We could redefine buildSuite on BagTest to invoke allSelectors but this means in essence that we could do it on a lot of potential testcase classes that may be subclasses.
Or we could redefine buildSuite on IdentyBagTest but this means that the subclasses should specify it. May be this solution is the best but I wanted to get your thoughts.
Of course this idea of inheriting test case make sense when superclass setup can be reused in subclasses one. So the default behavior of buildSuite always invoking all testmethods may not be so good but then via subclassing from BagTest if this is not to reuse it.
Stef
On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote:
A change have been saved in 'PharoInBox' for class TestCase in package SUnit so that suite are now built from allSelectors. This makes sense when you have testcase classes which inherits from each other and have parametrized (hook-based) setup.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ 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, Apr 29, 2009 at 7:09 PM, Lukas Renggli <renggli@gmail.com> wrote:
There is already such a switch that can be overridden in TestCase class>>#shouldInheritSelectors.
That's true. There was a discussion in squeak-dev. Here: http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/132946/focu... greetings mariano
Lukas
On Wed, Apr 29, 2009 at 10:03 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Maybe add a switch runSuperTests "Tells whether test from superclass should be run. By default, this is true. If you don't want to run superclass tests, redefine this as false in your subclass."
^true
2009/4/29 Stéphane Ducasse <stephane.ducasse@inria.fr>:
HI guys
I was coding this afternoon with Cyrille who is working a lot to improve the test coverage of collections. And we found a bit strange that when a testcase inherits from another one the tests of the superclass are not run. I checked a bit SUnit code and superclass testmethods are only run is the superclass is abstract or if there are not testmethods. Imagine BagTest IdentityBagTest
We could redefine buildSuite on BagTest to invoke allSelectors but this means in essence that we could do it on a lot of potential testcase classes that may be subclasses.
Or we could redefine buildSuite on IdentyBagTest but this means that the subclasses should specify it. May be this solution is the best but I wanted to get your thoughts.
Of course this idea of inheriting test case make sense when superclass setup can be reused in subclasses one. So the default behavior of buildSuite always invoking all testmethods may not be so good but then via subclassing from BagTest if this is not to reuse it.
Stef
On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote:
A change have been saved in 'PharoInBox' for class TestCase in package SUnit so that suite are now built from allSelectors. This makes sense when you have testcase classes which inherits from each other and have parametrized (hook-based) setup.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ 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
Thanks I forgot it. Stef On Apr 30, 2009, at 12:09 AM, Lukas Renggli wrote:
There is already such a switch that can be overridden in TestCase class>>#shouldInheritSelectors.
Lukas
On Wed, Apr 29, 2009 at 10:03 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Maybe add a switch runSuperTests "Tells whether test from superclass should be run. By default, this is true. If you don't want to run superclass tests, redefine this as false in your subclass."
^true
2009/4/29 Stéphane Ducasse <stephane.ducasse@inria.fr>:
HI guys
I was coding this afternoon with Cyrille who is working a lot to improve the test coverage of collections. And we found a bit strange that when a testcase inherits from another one the tests of the superclass are not run. I checked a bit SUnit code and superclass testmethods are only run is the superclass is abstract or if there are not testmethods. Imagine BagTest IdentityBagTest
We could redefine buildSuite on BagTest to invoke allSelectors but this means in essence that we could do it on a lot of potential testcase classes that may be subclasses.
Or we could redefine buildSuite on IdentyBagTest but this means that the subclasses should specify it. May be this solution is the best but I wanted to get your thoughts.
Of course this idea of inheriting test case make sense when superclass setup can be reused in subclasses one. So the default behavior of buildSuite always invoking all testmethods may not be so good but then via subclassing from BagTest if this is not to reuse it.
Stef
On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote:
A change have been saved in 'PharoInBox' for class TestCase in package SUnit so that suite are now built from allSelectors. This makes sense when you have testcase classes which inherits from each other and have parametrized (hook-based) setup.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ 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
I don't think it is a good idea to have hierarchies with test cases... depending on how you are doing it, it could couple the test hierarchy with the model hierarchy and I don't think that is a good idea...It also introduces some complexity, for example the number of tests are not only the test methods but for each concrete test class, the test methods on it plus the test methods of the abstract superclasses... hmmm I don't know, it is not natural at least for me too user inheritance with tests... On Wed, Apr 29, 2009 at 4:46 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
HI guys
I was coding this afternoon with Cyrille who is working a lot to improve the test coverage of collections. And we found a bit strange that when a testcase inherits from another one the tests of the superclass are not run. I checked a bit SUnit code and superclass testmethods are only run is the superclass is abstract or if there are not testmethods. Imagine BagTest IdentityBagTest
We could redefine buildSuite on BagTest to invoke allSelectors but this means in essence that we could do it on a lot of potential testcase classes that may be subclasses.
Or we could redefine buildSuite on IdentyBagTest but this means that the subclasses should specify it. May be this solution is the best but I wanted to get your thoughts.
Of course this idea of inheriting test case make sense when superclass setup can be reused in subclasses one. So the default behavior of buildSuite always invoking all testmethods may not be so good but then via subclassing from BagTest if this is not to reuse it.
Stef
On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote:
A change have been saved in 'PharoInBox' for class TestCase in package SUnit so that suite are now built from allSelectors. This makes sense when you have testcase classes which inherits from each other and have parametrized (hook-based) setup.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hernan Wilkinson wrote:
I don't think it is a good idea to have hierarchies with test cases... depending on how you are doing it, it could couple the test hierarchy with the model hierarchy and I don't think that is a good idea... It also introduces some complexity, for example the number of tests are not only the test methods but for each concrete test class, the test methods on it plus the test methods of the abstract superclasses... hmmm I don't know, it is not natural at least for me too user inheritance with tests...
+1 Besides, one of the goals of the testing is to test "external behavior" of the classes. This means, to me, that the test cases must test the classes without knowing if B inherits from A o if both B and C are subclasses of A. This way, when you for some reason must refactor or reorganize your classes, the test will not break as long as the external behavior of them remains unchanged. Summary, the inheritance of the classes tested is just an implementation detail, not something the test cases must care of. Cheers, Miguel Cobá
On Wed, Apr 29, 2009 at 4:46 PM, Stéphane Ducasse <stephane.ducasse@inria.fr <mailto:stephane.ducasse@inria.fr>> wrote:
HI guys
I was coding this afternoon with Cyrille who is working a lot to improve the test coverage of collections. And we found a bit strange that when a testcase inherits from another one the tests of the superclass are not run. I checked a bit SUnit code and superclass testmethods are only run is the superclass is abstract or if there are not testmethods. Imagine BagTest IdentityBagTest
We could redefine buildSuite on BagTest to invoke allSelectors but this means in essence that we could do it on a lot of potential testcase classes that may be subclasses.
Or we could redefine buildSuite on IdentyBagTest but this means that the subclasses should specify it. May be this solution is the best but I wanted to get your thoughts.
Of course this idea of inheriting test case make sense when superclass setup can be reused in subclasses one. So the default behavior of buildSuite always invoking all testmethods may not be so good but then via subclassing from BagTest if this is not to reuse it.
Stef
On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote:
> A change have been saved in 'PharoInBox' for class TestCase in > package SUnit > so that suite are now built from allSelectors. > This makes sense when you have testcase classes which inherits from > each other and have parametrized (hook-based) setup. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
The question is not at all to know if class B inherits from class A. It is that class A and B respond to a common API, whatever the implementation - inheritance or not. In this case, TestA and TestB share a common test protocol for testing the same API. That's why Stef & al started rewriting collection tests by composition with traits. The other more traditional, much simpler (toolwise) but less powerfull way is to use inheritance, so the question makes sense. What I read here indicates you prefer maintaining many duplicates of the test. And when you realize that one of the test was buggy (not the method that is tested, but the test itself), you certainly prefer to track all the copies and probably leave a buggy one here and there... Rethorical debates are fine, but it would be more enlightning to discuss around some chosen examples. Nicolas 2009/4/30 Miguel Enrique Cobá MartÃnez <miguel.coba@gmail.com>:
Hernan Wilkinson wrote:
I don't think it is a good idea to have hierarchies with test cases... depending on how you are doing it, it could couple the test hierarchy with the model hierarchy and I don't think that is a good idea... It also introduces some complexity, for example the number of tests are not only the test methods but for each concrete test class, the test methods on it plus the test methods of the abstract superclasses... hmmm I don't know, it is not natural at least for me too user inheritance with tests...
+1 Besides, one of the goals of the testing is to test "external behavior" of the classes. This means, to me, that the test cases must test the classes without knowing if B inherits from A o if both B and C are subclasses of A. This way, when you for some reason must refactor or reorganize your classes, the test will not break as long as the external behavior of them remains unchanged.
Summary, the inheritance of the classes tested is just an implementation detail, not something the test cases must care of.
Cheers, Miguel Cobá
On Wed, Apr 29, 2009 at 4:46 PM, Stéphane Ducasse <stephane.ducasse@inria.fr <mailto:stephane.ducasse@inria.fr>> wrote:
  HI guys
  I was coding this afternoon with Cyrille who is working a lot to   improve the test coverage of collections.   And we found a bit strange that when a testcase inherits from another   one the tests of the superclass are not run.   I checked a bit SUnit code and superclass testmethods are only run is   the superclass is abstract or if there are not testmethods.   Imagine       BagTest           IdentityBagTest
  We could redefine buildSuite on BagTest to invoke allSelectors   but this means in essence that we could do it on a lot of potential   testcase classes that may be subclasses.
  Or we could redefine buildSuite on IdentyBagTest but this means that   the subclasses should specify it.   May be this solution is the best but I wanted to get your thoughts.
  Of course this idea of inheriting test case make sense when superclass   setup can be reused in subclasses one.   So the default behavior of buildSuite always invoking all testmethods   may not be so good but then   via subclassing from BagTest if this is not to reuse it.
  Stef
  On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote:
   > A change have been saved in 'PharoInBox' for class TestCase in    > package SUnit    > so that suite are now built from allSelectors.    > This makes sense when you have testcase classes which inherits from    > each other and have parametrized (hook-based) setup.    >    >    > _______________________________________________    > Pharo-project mailing list    > Pharo-project@lists.gforge.inria.fr   <mailto:Pharo-project@lists.gforge.inria.fr>    > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project    >
  _______________________________________________   Pharo-project mailing list   Pharo-project@lists.gforge.inria.fr   <mailto:Pharo-project@lists.gforge.inria.fr>   http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Apr 30, 2009, at 8:08 AM, Nicolas Cellier wrote:
The question is not at all to know if class B inherits from class A. It is that class A and B respond to a common API, whatever the implementation - inheritance or not. In this case, TestA and TestB share a common test protocol for testing the same API.
Thanks for answering for me :) By inheriting I do not bind BagIdentitySet to BagTest. I reuse what can be reused.
That's why Stef & al started rewriting collection tests by composition with traits. The other more traditional, much simpler (toolwise) but less powerfull way is to use inheritance, so the question makes sense.
especially since we want to minimize duplicated code
What I read here indicates you prefer maintaining many duplicates of the test. And when you realize that one of the test was buggy (not the method that is tested, but the test itself), you certainly prefer to track all the copies and probably leave a buggy one here and there...
Rethorical debates are fine, but it would be more enlightning to discuss around some chosen examples.
The new tests for Collections are (soon a bit more clean) in PharoTaskForces in MC. We are starting to have a good coverage and a set of traits. The idea is that soon we will be able to test new collection classes by aggregating trait tests. Stef
2009/4/30 Miguel Enrique Cobá MartÃnez <miguel.coba@gmail.com>:
Hernan Wilkinson wrote:
I don't think it is a good idea to have hierarchies with test cases... depending on how you are doing it, it could couple the test hierarchy with the model hierarchy and I don't think that is a good idea... It also introduces some complexity, for example the number of tests are not only the test methods but for each concrete test class, the test methods on it plus the test methods of the abstract superclasses... hmmm I don't know, it is not natural at least for me too user inheritance with tests...
+1 Besides, one of the goals of the testing is to test "external behavior" of the classes. This means, to me, that the test cases must test the classes without knowing if B inherits from A o if both B and C are subclasses of A. This way, when you for some reason must refactor or reorganize your classes, the test will not break as long as the external behavior of them remains unchanged.
Summary, the inheritance of the classes tested is just an implementation detail, not something the test cases must care of.
Cheers, Miguel Cobá
On Wed, Apr 29, 2009 at 4:46 PM, Stéphane Ducasse <stephane.ducasse@inria.fr <mailto:stephane.ducasse@inria.fr>> wrote:
HI guys
I was coding this afternoon with Cyrille who is working a lot to improve the test coverage of collections. And we found a bit strange that when a testcase inherits from another one the tests of the superclass are not run. I checked a bit SUnit code and superclass testmethods are only run is the superclass is abstract or if there are not testmethods. Imagine BagTest IdentityBagTest
We could redefine buildSuite on BagTest to invoke allSelectors but this means in essence that we could do it on a lot of potential testcase classes that may be subclasses.
Or we could redefine buildSuite on IdentyBagTest but this means that the subclasses should specify it. May be this solution is the best but I wanted to get your thoughts.
Of course this idea of inheriting test case make sense when superclass setup can be reused in subclasses one. So the default behavior of buildSuite always invoking all testmethods may not be so good but then via subclassing from BagTest if this is not to reuse it.
Stef
On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote:
> A change have been saved in 'PharoInBox' for class TestCase in > package SUnit > so that suite are now built from allSelectors. > This makes sense when you have testcase classes which inherits from > each other and have parametrized (hook-based) setup. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
What I read here indicates you prefer maintaining many duplicates of the test. And when you realize that one of the test was buggy (not the method that is tested, but the test itself), you certainly prefer to track all the copies and probably leave a buggy one here and there...
nop nop... that was not my intention. If there is "duplicate code", then it should be reified. Traits is an option and we did that with Acciaressi and Butarelli thesis (same problem). Another option is just normal delegation. Bye, Hernan
Rethorical debates are fine, but it would be more enlightning to discuss around some chosen examples.
Nicolas
2009/4/30 Miguel Enrique Cobá MartÃnez <miguel.coba@gmail.com>:
Hernan Wilkinson wrote:
I don't think it is a good idea to have hierarchies with test cases... depending on how you are doing it, it could couple the test hierarchy with the model hierarchy and I don't think that is a good idea... It also introduces some complexity, for example the number of tests are not only the test methods but for each concrete test class, the test methods on it plus the test methods of the abstract superclasses... hmmm I don't know, it is not natural at least for me too user inheritance with tests...
+1 Besides, one of the goals of the testing is to test "external behavior" of the classes. This means, to me, that the test cases must test the classes without knowing if B inherits from A o if both B and C are subclasses of A. This way, when you for some reason must refactor or reorganize your classes, the test will not break as long as the external behavior of them remains unchanged.
Summary, the inheritance of the classes tested is just an implementation detail, not something the test cases must care of.
Cheers, Miguel Cobá
On Wed, Apr 29, 2009 at 4:46 PM, Stéphane Ducasse <stephane.ducasse@inria.fr <mailto:stephane.ducasse@inria.fr>> wrote:
HI guys
I was coding this afternoon with Cyrille who is working a lot to improve the test coverage of collections. And we found a bit strange that when a testcase inherits from
another
one the tests of the superclass are not run. I checked a bit SUnit code and superclass testmethods are only run
is
the superclass is abstract or if there are not testmethods. Imagine BagTest IdentityBagTest
We could redefine buildSuite on BagTest to invoke allSelectors but this means in essence that we could do it on a lot of potential testcase classes that may be subclasses.
Or we could redefine buildSuite on IdentyBagTest but this means that the subclasses should specify it. May be this solution is the best but I wanted to get your thoughts.
Of course this idea of inheriting test case make sense when
superclass
setup can be reused in subclasses one. So the default behavior of buildSuite always invoking all
testmethods
may not be so good but then via subclassing from BagTest if this is not to reuse it.
Stef
On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote:
> A change have been saved in 'PharoInBox' for class TestCase in > package SUnit > so that suite are now built from allSelectors. > This makes sense when you have testcase classes which inherits
from
> each other and have parametrized (hook-based) setup. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr> >
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
My mind keep thinking about this and I realized that the problem with reusing sunit test cases is more a tool related problem. I mean, nothing stop us from doing something like this:------- TestCase subclass: #EnumerationTest instanceVariableNames: 'collection' etc. EnumerationTest>>testDo collection do: [ :x | self assert: what ever has to be tested.... ]. EnumerationTest>>testSelect collection select: [ what ever has to be tested ... ] EnumerationTest>>collection: aCollection collection := aCollection. ----- Then if you want to run it with an array, we can do something like this: EnumerationTest buildSuite tests do: [ :aTest | aTest collection: #(1 2 3) ]; run. or with a OrderedCollection EnumerationTest buildSuite tests do: [ :aTest | aTest collection: (OrderedCollection with: 1 ....) ]; run. etc. The problem with this is that the test runner assumes that test cases are made up from subclasses of TestCase, a really bad coupling... so, if we want to keep running test from the test runner, we can: 1) Create a test case per collection type and create a test method per test method in EnumerationTest... TestCase subclass: #ArrayTest ArrayTest>> testDo (EnumerationTest selector: #testDo) collection: #(1 2 3); run. etc. a really ugly thing 2) Redefine testSelectors in ArrayTest, OrderedCollectionTest to do something like this: testSelectors ^EnumerationTest testSelectors buildSuiteFromLocalSelectors ^(super buildSuiteFromLocalSelectors) tests do: [ :aTest | aTest collection: ... ] 3) Or just open the test runner with a suite... something like: TestRunner open runSuite; ( EnumerationTest buildSuite tests do: [ :aTest | aTest collection: #(1 2 3) ]; yourself) Anyway, I think the problem of reusing tests with SUnit is more related with the tools we use to run the tests and not with the TestCase hierarchy, although it is not straightforward to reuse tests with it. Bye, Hernan On Thu, Apr 30, 2009 at 9:56 AM, Hernan Wilkinson < hernan.wilkinson@gmail.com> wrote:
What I read here indicates you prefer maintaining many duplicates of the
test. And when you realize that one of the test was buggy (not the method that is tested, but the test itself), you certainly prefer to track all the copies and probably leave a buggy one here and there...
nop nop... that was not my intention. If there is "duplicate code", then it should be reified. Traits is an option and we did that with Acciaressi and Butarelli thesis (same problem). Another option is just normal delegation.
Bye, Hernan
Rethorical debates are fine, but it would be more enlightning to discuss around some chosen examples.
Nicolas
2009/4/30 Miguel Enrique Cobá MartÃnez <miguel.coba@gmail.com>:
Hernan Wilkinson wrote:
I don't think it is a good idea to have hierarchies with test cases... depending on how you are doing it, it could couple the test hierarchy with the model hierarchy and I don't think that is a good idea... It also introduces some complexity, for example the number of tests are not only the test methods but for each concrete test class, the test methods on it plus the test methods of the abstract superclasses... hmmm I don't know, it is not natural at least for me too user inheritance with tests...
+1 Besides, one of the goals of the testing is to test "external behavior" of the classes. This means, to me, that the test cases must test the classes without knowing if B inherits from A o if both B and C are subclasses of A. This way, when you for some reason must refactor or reorganize your classes, the test will not break as long as the external behavior of them remains unchanged.
Summary, the inheritance of the classes tested is just an implementation detail, not something the test cases must care of.
Cheers, Miguel Cobá
On Wed, Apr 29, 2009 at 4:46 PM, Stéphane Ducasse <stephane.ducasse@inria.fr <mailto:stephane.ducasse@inria.fr>> wrote:
HI guys
I was coding this afternoon with Cyrille who is working a lot to improve the test coverage of collections. And we found a bit strange that when a testcase inherits from
another
one the tests of the superclass are not run. I checked a bit SUnit code and superclass testmethods are only run
is
the superclass is abstract or if there are not testmethods. Imagine BagTest IdentityBagTest
We could redefine buildSuite on BagTest to invoke allSelectors but this means in essence that we could do it on a lot of potential testcase classes that may be subclasses.
Or we could redefine buildSuite on IdentyBagTest but this means
that
the subclasses should specify it. May be this solution is the best but I wanted to get your thoughts.
Of course this idea of inheriting test case make sense when
superclass
setup can be reused in subclasses one. So the default behavior of buildSuite always invoking all
testmethods
may not be so good but then via subclassing from BagTest if this is not to reuse it.
Stef
On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote:
> A change have been saved in 'PharoInBox' for class TestCase in > package SUnit > so that suite are now built from allSelectors. > This makes sense when you have testcase classes which inherits
from
> each other and have parametrized (hook-based) setup. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr> >
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I agree more or less :) Now with traits we just compose kind of first class protocols and the result is quite natural. stef On May 1, 2009, at 12:37 AM, Hernan Wilkinson wrote:
My mind keep thinking about this and I realized that the problem with reusing sunit test cases is more a tool related problem. I mean, nothing stop us from doing something like this: ------- TestCase subclass: #EnumerationTest instanceVariableNames: 'collection' etc.
EnumerationTest>>testDo
collection do: [ :x | self assert: what ever has to be tested.... ].
EnumerationTest>>testSelect
collection select: [ what ever has to be tested ... ]
EnumerationTest>>collection: aCollection
collection := aCollection. ----- Then if you want to run it with an array, we can do something like this:
EnumerationTest buildSuite tests do: [ :aTest | aTest collection: #(1 2 3) ]; run.
or with a OrderedCollection
EnumerationTest buildSuite tests do: [ :aTest | aTest collection: (OrderedCollection with: 1 ....) ]; run.
etc. The problem with this is that the test runner assumes that test cases are made up from subclasses of TestCase, a really bad coupling... so, if we want to keep running test from the test runner, we can: 1) Create a test case per collection type and create a test method per test method in EnumerationTest... TestCase subclass: #ArrayTest ArrayTest>> testDo (EnumerationTest selector: #testDo) collection: #(1 2 3); run. etc. a really ugly thing 2) Redefine testSelectors in ArrayTest, OrderedCollectionTest to do something like this: testSelectors ^EnumerationTest testSelectors buildSuiteFromLocalSelectors ^(super buildSuiteFromLocalSelectors) tests do: [ :aTest | aTest collection: ... ] 3) Or just open the test runner with a suite... something like:
TestRunner open runSuite; ( EnumerationTest buildSuite tests do: [ :aTest | aTest collection: #(1 2 3) ]; yourself)
Anyway, I think the problem of reusing tests with SUnit is more related with the tools we use to run the tests and not with the TestCase hierarchy, although it is not straightforward to reuse tests with it.
Bye, Hernan
On Thu, Apr 30, 2009 at 9:56 AM, Hernan Wilkinson <hernan.wilkinson@gmail.com
wrote:
What I read here indicates you prefer maintaining many duplicates of the test. And when you realize that one of the test was buggy (not the method that is tested, but the test itself), you certainly prefer to track all the copies and probably leave a buggy one here and there...
nop nop... that was not my intention. If there is "duplicate code", then it should be reified. Traits is an option and we did that with Acciaressi and Butarelli thesis (same problem). Another option is just normal delegation.
Bye, Hernan
Rethorical debates are fine, but it would be more enlightning to discuss around some chosen examples.
Nicolas
2009/4/30 Miguel Enrique Cobá MartÃnez <miguel.coba@gmail.com>:
Hernan Wilkinson wrote:
I don't think it is a good idea to have hierarchies with test cases... depending on how you are doing it, it could couple the test hierarchy with the model hierarchy and I don't think that is a good idea... It also introduces some complexity, for example the number of tests are not only the test methods but for each concrete test class, the test methods on it plus the test methods of the abstract superclasses... hmmm I don't know, it is not natural at least for me too user inheritance with tests...
+1 Besides, one of the goals of the testing is to test "external behavior" of the classes. This means, to me, that the test cases must test the classes without knowing if B inherits from A o if both B and C are subclasses of A. This way, when you for some reason must refactor or reorganize your classes, the test will not break as long as the external behavior of them remains unchanged.
Summary, the inheritance of the classes tested is just an implementation detail, not something the test cases must care of.
Cheers, Miguel Cobá
On Wed, Apr 29, 2009 at 4:46 PM, Stéphane Ducasse <stephane.ducasse@inria.fr <mailto:stephane.ducasse@inria.fr>>
wrote:
HI guys
I was coding this afternoon with Cyrille who is working a lot
to
improve the test coverage of collections. And we found a bit strange that when a testcase inherits from
another
one the tests of the superclass are not run. I checked a bit SUnit code and superclass testmethods are
only run is
the superclass is abstract or if there are not testmethods. Imagine BagTest IdentityBagTest
We could redefine buildSuite on BagTest to invoke allSelectors but this means in essence that we could do it on a lot of
potential
testcase classes that may be subclasses.
Or we could redefine buildSuite on IdentyBagTest but this
means that
the subclasses should specify it. May be this solution is the best but I wanted to get your
thoughts.
Of course this idea of inheriting test case make sense when
superclass
setup can be reused in subclasses one. So the default behavior of buildSuite always invoking all
testmethods
may not be so good but then via subclassing from BagTest if this is not to reuse it.
Stef
On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote:
> A change have been saved in 'PharoInBox' for class
TestCase in
> package SUnit > so that suite are now built from allSelectors. > This makes sense when you have testcase classes which
inherits from
> each other and have parametrized (hook-based) setup. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, May 1, 2009 at 7:00 AM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
I agree more or less :)
jeje
Now with traits we just compose kind of first class protocols and the result is quite natural.
yes, it is true... I just wonder which one is better from the "theorical" point of view, if there is really a better one. Bye, Hernan.
stef On May 1, 2009, at 12:37 AM, Hernan Wilkinson wrote:
My mind keep thinking about this and I realized that the problem with reusing sunit test cases is more a tool related problem. I mean, nothing stop us from doing something like this: ------- TestCase subclass: #EnumerationTest instanceVariableNames: 'collection' etc.
EnumerationTest>>testDo
collection do: [ :x | self assert: what ever has to be tested.... ].
EnumerationTest>>testSelect
collection select: [ what ever has to be tested ... ]
EnumerationTest>>collection: aCollection
collection := aCollection. ----- Then if you want to run it with an array, we can do something like this:
EnumerationTest buildSuite tests do: [ :aTest | aTest collection: #(1 2 3) ]; run.
or with a OrderedCollection
EnumerationTest buildSuite tests do: [ :aTest | aTest collection: (OrderedCollection with: 1 ....) ]; run.
etc. The problem with this is that the test runner assumes that test cases are made up from subclasses of TestCase, a really bad coupling... so, if we want to keep running test from the test runner, we can: 1) Create a test case per collection type and create a test method per test method in EnumerationTest... TestCase subclass: #ArrayTest ArrayTest>> testDo (EnumerationTest selector: #testDo) collection: #(1 2 3); run. etc. a really ugly thing 2) Redefine testSelectors in ArrayTest, OrderedCollectionTest to do something like this: testSelectors ^EnumerationTest testSelectors buildSuiteFromLocalSelectors ^(super buildSuiteFromLocalSelectors) tests do: [ :aTest | aTest collection: ... ] 3) Or just open the test runner with a suite... something like:
TestRunner open runSuite; ( EnumerationTest buildSuite tests do: [ :aTest | aTest collection: #(1 2 3) ]; yourself)
Anyway, I think the problem of reusing tests with SUnit is more related with the tools we use to run the tests and not with the TestCase hierarchy, although it is not straightforward to reuse tests with it.
Bye, Hernan
On Thu, Apr 30, 2009 at 9:56 AM, Hernan Wilkinson < hernan.wilkinson@gmail.com
wrote:
What I read here indicates you prefer maintaining many duplicates of the test. And when you realize that one of the test was buggy (not the method that is tested, but the test itself), you certainly prefer to track all the copies and probably leave a buggy one here and there...
nop nop... that was not my intention. If there is "duplicate code", then it should be reified. Traits is an option and we did that with Acciaressi and Butarelli thesis (same problem). Another option is just normal delegation.
Bye, Hernan
Rethorical debates are fine, but it would be more enlightning to discuss around some chosen examples.
Nicolas
2009/4/30 Miguel Enrique Cobá MartÃnez <miguel.coba@gmail.com>:
Hernan Wilkinson wrote:
I don't think it is a good idea to have hierarchies with test cases... depending on how you are doing it, it could couple the test hierarchy with the model hierarchy and I don't think that is a good idea... It also introduces some complexity, for example the number of tests are not only the test methods but for each concrete test class, the test methods on it plus the test methods of the abstract superclasses... hmmm I don't know, it is not natural at least for me too user inheritance with tests...
+1 Besides, one of the goals of the testing is to test "external behavior" of the classes. This means, to me, that the test cases must test the classes without knowing if B inherits from A o if both B and C are subclasses of A. This way, when you for some reason must refactor or reorganize your classes, the test will not break as long as the external behavior of them remains unchanged.
Summary, the inheritance of the classes tested is just an implementation detail, not something the test cases must care of.
Cheers, Miguel Cobá
On Wed, Apr 29, 2009 at 4:46 PM, Stéphane Ducasse <stephane.ducasse@inria.fr <mailto:stephane.ducasse@inria.fr>>
wrote:
HI guys
I was coding this afternoon with Cyrille who is working a lot
to
improve the test coverage of collections. And we found a bit strange that when a testcase inherits from
another
one the tests of the superclass are not run. I checked a bit SUnit code and superclass testmethods are
only run is
the superclass is abstract or if there are not testmethods. Imagine BagTest IdentityBagTest
We could redefine buildSuite on BagTest to invoke allSelectors but this means in essence that we could do it on a lot of
potential
testcase classes that may be subclasses.
Or we could redefine buildSuite on IdentyBagTest but this
means that
the subclasses should specify it. May be this solution is the best but I wanted to get your
thoughts.
Of course this idea of inheriting test case make sense when
superclass
setup can be reused in subclasses one. So the default behavior of buildSuite always invoking all
testmethods
may not be so good but then via subclassing from BagTest if this is not to reuse it.
Stef
On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote:
> A change have been saved in 'PharoInBox' for class
TestCase in
> package SUnit > so that suite are now built from allSelectors. > This makes sense when you have testcase classes which
inherits from
> each other and have parametrized (hook-based) setup. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr> >
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr <mailto:Pharo-project@lists.gforge.inria.fr>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
Cyrille Delaunay -
Hernan Wilkinson -
Lukas Renggli -
Mariano Martinez Peck -
Miguel Enrique Cobá MartÃnez -
Nicolas Cellier -
Stéphane Ducasse