[Pharo-project] run all tests from superClass

Hernan Wilkinson hernan.wilkinson at gmail.com
Thu Apr 30 08:56:45 EDT 2009


> 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 at 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 at inria.fr <mailto:stephane.ducasse at 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 at lists.gforge.inria.fr
> >>     <mailto:Pharo-project at lists.gforge.inria.fr>
> >>      >
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>      >
> >>
> >>
> >>     _______________________________________________
> >>     Pharo-project mailing list
> >>     Pharo-project at lists.gforge.inria.fr
> >>     <mailto:Pharo-project at lists.gforge.inria.fr>
> >>     http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >>
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Pharo-project mailing list
> >> Pharo-project at lists.gforge.inria.fr
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> >
> > _______________________________________________
> > Pharo-project mailing list
> > Pharo-project at lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090430/127cd67a/attachment-0001.html>


More information about the Pharo-dev mailing list