I have published an 'evolutionary' version of the SUnit improvements
that I have mentioned previously. http://bugs.impara.de/view.php?id=5639 In short, this extends the TestRunner to provide a selectable list of test suites published by test classes. e.g. StandardTests LongTests Squeak310Tests Squeak39Tests KnownIssues PerformanceMeasures best regards Keith ___________________________________________________________ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html |
stephane ducasse wrote:
> Hi keith > > could you give an example to make clear the point of selectable list. > > Stef > >> >> In short, this extends the TestRunner to provide a selectable list of >> test suites published by test classes. >> >> e.g. >> >> StandardTests >> LongTests >> Squeak310Tests >> Squeak39Tests >> KnownIssues >> PerformanceMeasures LongTestCase has been in SUnit for a while suggesting that there is a case for optional suites of tests, yet there has been no UI support for toggling the value of RunLongTestCases. I have added this code to SUnit (in ST/X) for almost 7 years which allows a test case to publish suites. I used this in order to support a product which simulated several releases of a piece of hardware, all in a single image. This selectable list allows you to select "All Standard Tests" and "LongTests". It allows you to select "All Standard Tests" and "Squeak310Tests" specific to a 310 release. It allos you to define additional suites such as "Performance Measures" which will be slow but generate a performance report on various features. It provides a slot for putting tests that do not yet work "known issues", or "todo" items. does that help? best regards Keith Send instant messages to your online friends http://uk.messenger.yahoo.com |
The TestRunner improvement that I have recently released is available in
http://www.squeaksource.com/Testing comments would be welcomed. ---- This version of TestRunner gives a list of published suites allowing you to define as many different suites as you wish. These may be for given domains, releases, products, deployment situations, known issues etc. I have improved the TestRunner GUI to provide a minimal "Explain Suites" option. This explains each of the published Test Suites as defined by each TestCase class. (it does this by collating the method comments that define each published suite) This "finally" imparts an ability to comment on sets of tests communicating design/test intent and context information to the users of the tests. I am particularly interested in user feedback on this concept. best regards Keith ---- class comment follows: Modification Notes: KPH 26/10/06 ====================================== Removed the magic that a TestCase subclass with no test selectors automatically inherits testSelectors. This can and should be explicitly set by overriding #shouldInheritSelectors to true so as to make the behaviour explicit. Simplification/refactoring: All hard wired references to 'test*' have been removed from the suiteBuild protocol, indeed the suiteBuild protocol has been greatly simplified/removed. The same capability is implemented with 6 less methods on the class side of TestCase More flexible suite building API: Asking an abstract class for #suite: will build the entire suite for all of its concrete subclasses. Asking a concrete class for #suite: will just return the suite for that one class. The suite building api now matches against method selector and category ("selector@category"). Multiple matches may be specified. Exclusions may be defined. Suites are defined as class methods for a testcase class. example: myTestSuite "all 'test' methods, but not those in categories 'long tests', or 'broken' ^ 'test*|^*@long tests|^*@broken' Suites are obtained via either a) a selector which references the defined suite or b) an explicit string. TestCase suite: #myTestSuite. TestCase suite: 'test*|longtest*' Suites may be defined as an array combining other suites example: myTestSuiteWithLongTests ^ #( #myTestSuite '*@long tests' ) Published Suites API #publishedSuites provides a list of test suites published by each TestCase class that can be picked in the TestRunner. This provides a natural UI for selecting from a range of testing scenarios. e.g. tests for different products, releases, platforms, performance monitoring tests, long tests, tests needing additional services (db) i.e TestCase publishes #standardTests, whereas LongTestCase publishes #longTests, but not #standardTests. LongTestCase Simplified Any class can now mark some tests as being long and mark them to be published accordingly. i.e. #longTests ^self suite: 'longtest*'. Alternatively any class can mark all of its tests as long i.e. #longTests ^self suite: 'test*|longtest*', and not publish #standardTests. With this new publishing suites API the functionality of LongTestCase is no longer needed. It could be removed but is left for backwards compatibility. Additional asserts added #assert:equals and #assert:includes ___________________________________________________________ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html |
Use case: (a short story!)
You have written a TestCase class that tests your code in 3.8 In moving to 3.9 some test cases fail. If you re-write those test cases then you have to keep two versions of your TestCase class, one for 3.8 and another for 3.9. Solution: Categorise the failing test cases as '3.8- only' to indicate that they only work in versions 3.8 and earlier. add the following: MyTestCases-c-#publishedSuites #( #standardTests #squeak38AndEarlier ) and: MyTestCases-c-squeak38AndEarlier ^('*@v38-*only' #squeak37AndEarlier) and if not already inherited. MyTestCases-c-standardTests "all tests except any categorised under '*only' " ^( '*test|^*@only' ) cheers Keith ___________________________________________________________ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html |
Thinking out load.
In future releases this 'versioning' capability which is entirely defined in class methods could be added as a Trait to your TestCase rather than modifying the superclass TestCase or subclassing TestCaseVersioned. Keith Send instant messages to your online friends http://uk.messenger.yahoo.com |
Free forum by Nabble | Edit this page |