Hmm... we're using TestBrowser and it doesn't seem to do anything 
special about TestSuites - just lets you run categories of tests easily.

I suppose you could set up a TestSuite for failing tests, but unless you 
actually remove the tests from their proper TestCases, running that 
TestCase will still cause errors.  Then I suppose you can create a 
TestSuite for passing tests, but you have still lost the flexibility of 
being able to run individual TestCases.  And I don't like the idea of 
actually removing the test from the TestCase because you don't know 
which TestCase it needs to go back to when it passes again.

It feels like this is another case where we need meta-information 
associated with methods - but the best workaround I know of is to have 
another method hold the meta-information.

Still - better tools would make a big difference however we do it - when 
I have time to look at this further, I would definitely look at the 
testing UIs.  Is there any interest in having a solution to this problem 
or will I just keep it in the realm of Personal Hacks? :)

Julian

Daniel Vainsencher wrote:
> I mean a way of naming and storing a bunch of related tests. TestSuite
> gives you the test composition abstraction, you need to store a
> TestSuite for the "expected failures", and then separately run the
> "expected failure" and the "regression" (everything else) parts of the
> test suite.
> 
> This would require a little supporting UI and process to use, but it
> doesn't seem to require a lot of work. I don't know but I've been told
> that TestBrowser allows one to partition the tests more logically. Maybe
> it supports TestSuites somehow.
> 
> Daniel
> 
> Julian Fitzell <julian at beta4.com> wrote:
> 
>>Can you expand more on what you mean by organizing structure?
>>
>>Daniel Vainsencher wrote:
>>
>>>I think the need you're addressing could be better met with some
>>>organizing structure on top of TestCases... and that would be useful. I
>>>remember the mess it was to find a few score of RB TestCases not
>>>working, and then finding out that they are actually in implicit layers
>>>- the parser should be fixed before the refactorings, and so forth.
>>>Would have been nice if the layers were explicit.
>>>
>>>Daniel
> 
>