search

jecisc / Bazard

0 stars 0 forks source link

SUnit does not manage well abstract test classes. #157

Closed jecisc closed 5 years ago

jecisc commented 5 years ago

Migrated case from Manuscript.

Original case: https://pharo.fogbugz.com/f/cases/20118 Status: Work Needed Project: SUnit Original Author: CyrilFerlicot Date: 3 June 2017 9:07:52 pm

Description:

Sometimes when you have an abstract test class and you override it the tests will be inherit or not.

If a subclass has other tests, the tests will not be inherited. If the subclass has no other tests, the tests will be inherited.

Here is a little script showing the problem:

TestCase subclass: #A slots: { } classVariables: { } category: 'TestProblem'.

A asClass subclass: #B

slots: {  }
classVariables: {  }
category: 'TestProblem'.

B asClass subclass: #C

slots: {  }
classVariables: {  }
category: 'TestProblem'.

A asClass class compile: 'isAbstract

^ self = A'.

A asClass compile: 'actualClass

^ self subclassResponsibility'.

A asClass compile: 'testTest

self actualClass new'.

C asClass buildSuiteFromAllSelectors run.

"1 run, 0 passes, 0 skipped, 0 expected failures, 0 failures, 1 errors, 0 unexpected passes"

C asClass compile: 'testAnotherTest

self assert: true'.

C asClass buildSuiteFromAllSelectors run.

"1 run, 1 passes, 0 skipped, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes"

In the last line I would expect 2 run cases. 1 pass and 1 error.

jecisc commented 5 years ago

Reply: Author: CyrilFerlicot Date: 4 June 2017 1:05:21 pm

Message:

Apparently this is not a bug but a feature. We are already 3 to think this is odd (Max, Monty and myself). I propose to change the behaviour early in Pharo 7 if nobody brings a good reason to not do it.

For more info: http://forum.world.st/Abstract-test-classes-are-not-managed-well-in-SUnit-td4949186.html

jecisc commented 5 years ago

Reply: Author: Andrew P Black Date: 27 October 2017 9:09:46 am

Message:

The current behaviour, as I understand it, is that if the test subclass has a class-side method #shouldInheritSelectors that answers true, then the inherited tests will be considered to be part of the test suite defined by that test subclass. If it answers false, the inherited tests will not be included in the test suite.

This seems like reasonable behavior — although I'm not sure if it is documented anywhere! What change are you proposing, exactly? To remove the somewhat convoluted inherited implementation of #shouldInheritSelectors from TestCase, and replace by ... what exactly?

jecisc commented 5 years ago

Reply: Author: Denis Kudryashov Date: 27 October 2017 9:52:49 am

Message:

I also prefer "inherit by default" behaviour

jecisc commented 5 years ago

Reply: Author: Andrew P Black Date: 14 November 2017 3:39:59 pm

Message:

So the proposal is to switch the default to inherit tests from a superclass of th test class?  If the programmer doesn't like that, then they should define the method #shouldInheritSelectors to answer false?

jecisc commented 5 years ago

Reply: Author: CyrilFerlicot Date: 14 November 2017 3:43 pm

Message:

Yes!

As you can see in the ML discussion above, there is much more case where we want to inherit, than case where we do not want to inherit.

jecisc commented 5 years ago

Reply: Author: Pavel Krivanek Date: 28 September 2018 9:30:35 am

Message:

Existed in Pharo 6