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.c...@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.duca...@inria.fr <mailto:stephane.duca...@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
