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 at 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