> 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