TestResources aren't something I've done much with. Recently, I did an update to SUnitToo TestResources to support them better. I hadn't done anything to the SUnitToo(ls) runner though, it still just raised an exception. Today, I fixed that. It handles TestResourceUnavailable exceptions much cleaner now (prints nice message, resets icon status); latest versions published in the Open/Public Repository.

I did this, because I wanted to try a simple experiment. I'm very loathe to add more thin API points on SUnitToo. When a feature comes up, I'd rather explore ways of putting the basics together, rather than fatten the API.

One such request that's been kicked around here at Cincom, is platform specific filters. We have a large suite of tests; a small subset of them really are platform specific. Sometimes people put preambles to their tests:

('*MacOSX' match: OSHandle currentPlatformID) ifFalse: [^self]

But this gets old, and you have to go look them up each time.

So I experimented with using TestResources to do this task. It turned out to be amazingly simple. Let's say I need to filter some graphics tests that are X11 specific, Windows specific, and MacOSX specific. I create three subclasses of TestResource named X11Only, MacOSXOnly, and WindowsOnly. I add one method to each.

isAvailable

	^Screen default platformName = 'X11'

isAvailable

	^Screen default platformName = 'MacOSX'

isAvailable

	^Screen default platformName = 'MS-Windows'

Now I can use these as resources for my tests that are platform specific. If they're not there, the tests will be skipped. SUnitToo actually can specify resources at the per test level, so you don't have to devolve to having special concrete test classes, inheriting off of abstract classes or anything like that. An X11 specific graphic test might look something like:

x11SpecificGraphicsText

	<test>

	<uses: #{X11Only}>



	self deny: 'blah' , blah' = 'yadayada'