Enables testing of the class side without disturbing the classes' soleInstance
TestReporter - Non Gui test runner
Reports test run progress
Reports failures/errors to file
Can read failures/errors file into a method browser
TestRunner
Browse selected test cases in a method browser
Method browser shows timings/net use
UI for selecting published suites
UI for applying filters to remove tests
UI for applying filters to select tests
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.
myCustomSuite , #todoFilter ) to be assembled adding and subtracting
TestSuite's (collections or tests) obtained using the following methods.
suiteWithFlagged: "looks for flag: #literal or Pragma: "
suiteWithMethodCategoryMatching: pattern "for sspec it would be specs"
suiteWithSelectorsMatching: pattern "the default is 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.