[squeak-dev] NetworkTests' TestURI vs. ClassTestCase

Tony Garnock-Jones tonyg at leastfixedpoint.com
Thu Jun 2 14:48:07 UTC 2022

Hello Patrick, hello all,

I just noticed some failures in TestURI in NetworkTests, and I'm 
wondering how to fix them most cleanly.

I've addressed this message to Patrick as well as the list, since he 
seems to have been the most recent contributor to NetworkTests, but I'd 
like to hear from anyone on the list!

So, three of the TestURI tests are failing now that it inherits from 

  - if it is renamed URITest, the tests pass (!!!); or,

  - if it is given an override "targetClass  ^ URI", the tests pass.

The override is a bit gross. So, perhaps we want to rename it to 
URITest, for consistency with other ClassTestCase subclasses. Do people 
agree? Shall I do that?

Relatedly: what is ClassTestCase >> classToBeTested for, now that 
targetClass exists? In *almost* every case, classToBeTested is set to 
yield the same answer as targetClass. However it's not quite *every* 
case :-( . It looks like classToBeTested is the earlier mechanism. It 
has the advantage of being explicit, and the disadvantage of being 
(extremely) repetitive. However, targetClass's default implementation is 
kind of icky, leading to the TestURI vs URITest problem noted above.

What should we do to clean it up? Prefer targetClass, or prefer 
classToBeTested? Neither? Both?? :-)


More information about the Squeak-dev mailing list