> On 23 Apr 2019, at 13:47, Tim Mackinnon <tim@testit.works> wrote:
>
> I you refactor some common tests and push them up to a superclass - e.g.
> (ProjectTestCase)
>
> TestCase
> + ProjectTestCase
> Domain1Test
> Domain2Test
>
>
> The tests you push up into ProjectTestCase won’t be run (like you would
> expect with a normal object using normal inheritance). You have to define a
> method #shouldInheritSelectors, which is quite subtle, and if you're not
> careful you won’t realise you aren’t running those tests. And if you later
> refactor again, you may silently break something.
Wow, I have been using inheritance in Unit Tests quite a lot (e.g.
STONWriteReadTests) and I knew about #isAbstract but not about
#shouldInheritSelectors
Looking at the standard implementation of #shouldInheritSelectors (which is
quite complex, never a good sign), I get a feeling why it never hurt me, but
still, this is indeed surprising and thus not good.
> Its an easy trap to fall into (like myself and colleague did). While I’m sure
> there was some rational when this was done many years ago, I’m just not sure
> it holds today (or if the full implications were realised). Like Cyril,
> several years ago - it just caught me out.
>
> A simple solution would be to have PharoTestCase - that works like normal
> objects, and our tools to create an initial test could just subclass it.
> TestCase can stay for compatibility?
>
> Anything we can do to make testing easier and safe has got to be a good
> thing? While I don’t like to propose diverging, it seems that the status quo
> will just prevail and future developers will make this same preventable
> mistake.
>
> Tim
>
>> On 23 Apr 2019, at 13:14, Tim Mackinnon <tim@testit.works> wrote:
>>
>> I just got burned by tests not inheriting from a TestCase superclass… I note
>> that in 2017, Cyril tried to argue to get this changed to work just like
>> normal objects (proposing that for P7 tests works like any other object…)
>> but I think it was just too difficult to argue against a decision made so
>> long ago.
>>
>> I tried to follow the 2017 logic about why you would want tests to operate
>> differently than other objects, but I couldn’t understand it. I did see that
>> some numbers run against Squeak Trunk argued that it was fine …. but I’m
>> left wondering about all the people with individual projects like me that
>> just expect objects to behave like objects and not have unexpected
>> behaviour. Deviating seems like extra complexity that I’d prefer not to have
>> to worry about.
>>
>> Given Pharo is revisiting the concept of testing (with Dr Test) - could we
>> possibly introduce the normal object behaviour somehow? Possibly we could
>> have a new superclass for Tests - and use it to move forward without
>> breaking existing stuff and those who want to stick with this other way of
>> thinking?
>>
>>
>> Tim
>>
>>
>>
>
>
