OK, for once, I like the name "pragmas", because I could use it for a fun blog title.

There's a new version of SUnitToo up in the Open Repository which allows one to specify a <test> method annotation. It works alongside the testMethodName convention. So you can use either convention. Of course, there's a new version of ExtraRBForSUnitToo as well.

I thought I'd try this, because other's have shown interest in it. I didn't think I'd take to it. I used TestTokenTest to actually try it out, and must say I actually liked it. I worried that it wouldn't be instantaneously obvious what was a test method and what wasn't. But with the test icons, you know instantly. So a version where all test methods are done via annotation rather than prefixing may be forthcoming.

Along with this change, I decided to simplify the whole shouldInheritSelectors stuff. This got kind of added on piece by piece to the original SUnit and I wasn't really satisfied with it. Upon reflection, it seems that any time you're creating extra subclass layers, you're doing so for abstraction's sake. So I've simply made it the case that any TestCase's "testSelectors" are all test methods (by annotation or prefix convention) between it and TestCase. No one really cares if a class isAbstract, except the UI. That was simplified to simply be a query based on whether the class has subclasses. If this gives anyone headaches, I'd love to hear about it. And work towards a solution.

There's a couple of things that are on the future road map for this stuff:

1. Cease using TestToken as a "test proxy", and use MethodDefinition instead. It has the ability to specify both receiving class and implementing class.
2. Modify the UI to automagically set visibility up to (but not including) TestCase when browsing TestCase subclasses.
3. Modify AllTestStatus, so that inherited tests work right in the browser
.