On Wed, Apr 29, 2009 at 7:09 PM, Lukas Renggli <[email protected]> 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/focus=132948 greetings mariano > > Lukas > > On Wed, Apr 29, 2009 at 10:03 PM, Nicolas Cellier > <[email protected]> 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 <[email protected]>: > >> 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 > >>> [email protected] > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [email protected] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > _______________________________________________ > > 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 >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
