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.
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
>
>
>
