Revisiting the inheritance of tests in 2019....
Locked
Revisiting the inheritance of tests in 2019....
 
|
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 |
Re: Revisiting the inheritance of tests in 2019....
|
|
What do you suggest ?
Right now, a unit test has to inherit from TestCase, seems quite logical to me. You want any object to be able to contain unit tests ? How do you want to mark them ? With a pragma ? What if I forget the pragma ? ;-) IOW, what exactly is the problem ? > On 23 Apr 2019, at 13:14, Tim Mackinnon <[hidden email]> 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 > > > |
Re: Revisiting the inheritance of tests in 2019....
|
|
In reply to this post by Tim Mackinnon
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 <[hidden email]> 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 > > > |
Re: Revisiting the inheritance of tests in 2019....
|
|
> On 23 Apr 2019, at 13:47, Tim Mackinnon <[hidden email]> 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 <[hidden email]> 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 >> >> >> > > |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |