[ANN] SUnit-#publishedSuites

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANN] SUnit-#publishedSuites

keith1y
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

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SUnit-#publishedSuites

keith1y
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
The point of the selectable list is demonstrated by the fact that
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 

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SUnit-#publishedSuites

keith1y
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

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SUnit-#publishedSuites UseCase

keith1y
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

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SUnit-#publishedSuites UseCase

keith1y
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