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: <suite: #literal>" #suiteWithMethodCategoryMatching: pattern "for sspec it would be specs*" #suiteWithSelectorsMatching: pattern "the default is test*" e.g. MyTestCaseClass-myCustomSuite ^ (self suiteWithSelectorsMatching: 'test*') , ( self suiteWithFlagged: #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. As we move to images that may have modules removed, we can add a mechanism for specifying "tests that only apply if a particular package is loaded." hope this helps to explain things a bit Keith