>> I need to set up various special state on all tests of a specialized
>> Suite during initialization of the Suite. But after creating the
>> tests, SUnit then promptly throws them all away which is not only
>> wasteful it loses all of my needed additional-state).
>>
>> setUp and tearDown are intended to, well, set up and tear down any
>> test. Any test that cannot "run again" is broken because it means its
>> setUp and tearDown methods don't do the job they're supposed to.
>>
>> If no objections, I will push this to trunk and delete the
>> #testRanOnlyOnce test.
>
> I don't know the details of your use case, but isn't this what TestResources
> are for? Why are you customizing the initialization of a Suite?
SUnit provides #suiteClass to allow one to create their own custom
TestSuite subclasses. This is *all that's needed* for SUnit to
accomodate the need for resources not to mention many many other
use-cases.
By contrast, the TestResource implementation is just plain bad design.
Very bad. For being overly complex (just look at
TestCase>>#resources), for the added dependencies on TestResource api
(#isAvailable, #reset), for the required overrides on the class-side
of the TestCase just to tell it the class names of the TestResources
(Geez!!), for employing global state to implement it --- what, oh
what, do I get for all of these negatives?
One crummy accessor, #resources which is.... (drum roll please) a Set!
Huh?! I guess that means I need to detect through it to look for
particular resources by class type? Baaaaad.
Which is why I prefer to just use good ol'e OO: Take advantage of
SUnits hook for defining my own TestSuite subclass with its own named
inst-vars for what it needs (resources or whatnot), and send #setUp
and #tearDown to it so it is consistent with treatment of TestCases
and all-around smaller and simpler.
But I do need for SUnit to not subvert its own hooks it provides for
folks doing it this way, which it does without this patch.
Locked
