Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
SUnit for 3.10
Last updated at 11:08 pm UTC on 3 October 2008

Script to load improved SUnit

usage:
Installer installUrl: 'wiki.squeak.org/squeak/SUnit%20for%203.10'.
author: kph
script:

Installer mantis fixBug: 5319.


Additional Features

  1. SUnit
    1. Suite defining mechanism
    2. Suite and Filter publishing interface
  2. TestResultTimed
    1. Collects test timings
    2. Collects whether a test uses the network
  3. TestCaseVersioned - Specialized TestCase class
    1. Categorize tests for platforms
    2. Categorize tests for image version
    3. Categorize tests for vm Version
  4. ClassClonerTestResource
    1. Enables testing of the class side without disturbing the classes' soleInstance
  5. TestReporter - Non Gui test runner
    1. Reports test run progress
    2. Reports failures/errors to file
    3. Can read failures/errors file into a method browser
  6. TestRunner
    1. Browse selected test cases in a method browser
    2. Method browser shows timings/net use
    3. UI for selecting published suites
    4. UI for applying filters to remove tests
    5. UI for applying filters to select tests
    6. UI for marking tests, as long

From the class comment:

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/enhancement:

All hard wired references to 'test*' have been removed from the suiteBuild protocol, indeed the suiteBuild protocol has been greatly simplified/removed.

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 latest SUnit in ss/Testing allows suites and filters (e.g.
  1. myCustomSuite , #todoFilter ) to be assembled adding and subtracting
TestSuite's (collections or tests) obtained using the following methods.

  1. suiteWithFlagged: "looks for flag: #literal or Pragma: "
  2. suiteWithMethodCategoryMatching: pattern "for sspec it would be specs"
  3. suiteWithSelectorsMatching: pattern "the default is test"

e.g.

MyTestCaseClass-myCustomSuite

^ (self suiteWithSelectorsMatching: 'test') , ( self suiteWithFlagged:
  1. test )

The custom suite is published on the class side of your TestCase class
in #publishedSuites ^ #( #allStandardTests #myCustomSuite ) , likewise
for #publishedFilters.

The TestRunner allows you to chose a suite, only the classes included in
the suite are displayed. This finally allows you to define a project to
work within, and have the UI ignore the other tests.

The TestRunner also allows you to either reject or select items in the
suite that match the filter. So you could run all of the todoItems from
mySuite, or all of the non-todo items from mySuite.

TestCaseVersioned makes extensive use of this. Tests in subclasses can
flag specifically which versions of squeak the test is expected to work
in, and on which platform.

This allow you to have some means of flagging pharo specific tests, i.e.
tests that you would only expect to work in pharo, and tests that you
would only expect to work in squeak. Thus we can still keep an "all
tests green" policy, even though we may have different tests for
different image-kernels.

Additional asserts

added #assert:equals and #assert:includes

Future:
The expectedFailures mechanism may not be needed anymore, and needlessly complicates the results.