[Lots of cool stuff snipped]
(In the future, we'd like to have the kind of TestCases that SUnit has now, but not have the overhead of doubling the number of classes. One way to do this is to make Metaclass do everything that TestCase does. The individual testing methods would begin with a standard prefix like 'textSU'. Any class that has a method whose name begins with 'textSU' would be found by TestRunner, and entered into its list. Any comments on this?)
We have found it useful to organize tests into categories (unit test, integration, performance, hmm - we now have a "broken" category). We have a different TestRunner that allows you to select the categories that you want to run (and some other enhancements). It has proven useful to run all of the unit tests without running the time-consuming performance tests, or vice-versa.
At the moment, this is all in VW and uses VW's pragma facilities for categorizing test methods. Add as many <category: #cat> lines as you want to a method, save and it shows up in the test runner.
Assuming nobody wants to volunteer to implement a similar pragma facility; an alternative way to do this is to use the standard method category with a naming convention (SUnit-performance,...) instead of relying on a naming convention for methods.
-david
At 4:04 PM -0500 11/30/01, Pennell, David wrote: [snip]
[snip] use the standard method category with a naming convention (SUnit-performance,...) instead of relying on a naming convention for methods.
This is an excellent idea that solves the problem very nicely. Any class that has test methods, simply puts them in some category that begins with 'SUnit'. TestRunner can find them from that.
----------- At 10:24 PM +0100 11/30/01, ducasse wrote:
The point of the class in SUnit is that it represents the context of the test. So I can have multiple instance variables and each method represent a test and share this context. With this merge we will end up to have the possibility or to simply express test or to use TestCase. However I'm wondering what this would means from a model point of view: metaclass will have another responsibility that is not only representing metaclass but also TestCase.
Yes, it is true that I am not prepared to introduce new instance variables into a metaclass to hold context across tests. But, a lot can be done without that. Perhaps one of you can suggest some kind of extension or workaround when inst vars are really needed in a TestCase class?
--Ted.
squeak-dev@lists.squeakfoundation.org