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