CincomSmalltalkWiki: SUnit Quickstart Notes

SUnit Quickstart Notes (Differences between version 4 and 3)

The following was forwarded by Peter Suk from the Camp Smalltalk mailing list. It's a good, quick introduction to how to use SUnit. This was originall written by Jeff Hallman. I've reformatted it somewhat for inclusion on the Wiki. The clear expression of how to use SUnit is his, any mistakes are mine.

SUnit quick start notes

TestCase -- the basic unit of testing. You create a fixture (a configuration of objects whose responses to messages you are going to check) as follows:

Subclass TestCase.
Add instance variables for each object in the configuration.
Override the inherited setUp method to initialize the fixture.

Example: I want to test operations on a my Vector class (not shown here). I create VectorTestCase as a subclass of TestCase, with two instance variables v1 and v2, initialized by:

VectorTestCase>>setUp
    v1 := Vector with:1 with:2 with:3 with:4.
    v2 := 10, 20, 30, 40.  "Also creates a Vector"

TestCase Methods -- For each predictable reaction you want to test, add a unary method to your TestCase subclass that represents that reaction. The method selector must match the pattern 'test*'. Let's call these testMethods. In your testMethod, you 'stimulate' the fixture, and expect certain results. You check the results with messages like:

self assert: aBoolean
self deny: aBoolean
self should: aBlock
self shouldnt: aBlock
self should: aBlock raise: anExceptionalEvent
self shouldnt: aBlock raise: anExceptionalEvent

Example: checking addition for the VectorTestCase fixture.

VectorTestCase>>testAdd
    n := v1 size.
    v3 := v1 + v2.
    self assert: v3 size = n.
    self assert: ((v3 at:1 = (v1 at:1) + (v2 at:1))).
    self assert: ((v3 at:n = (v1 at:n) + (v2 at:n))).

The "self setUp" message is sent before each testMethod is run, and "self tearDown" is sent afterwards (whether the testMethod fails or not). You can override the inherited tearDown method (which does nothing) in your TestCase subclass if you need some cleanup action after each testMethod runs.

Once you have created testMethods in your TestCase subclass, you start up the TestRunner application. It automatically searches your image for TestCase subclasses, and runs one TestCase or all of them at the touch of a button. You can easily invoke the debugger on testMethods that failed. The eXtreme Programming folks think you should write TestCase subclasses for every class you create, keep a TestRunner open at all times, and run all the tests every time you change anything. It's (usually) fast, and it's easy, so why not?

A note: SUnit as usually distributed comes with a bunch of tests on itself, some of which are supposed to fail. This means that if you tell the TestRunner app to Run All Tests, you'll get an annoying bunch of failures from the tests of SUnit itself. To fix this, go to a System browser and delete the class categories SUnitNamespaceTest and SUnitTests. Now the only tests that will show up are the ones you create.

+ + These notes should be in the SUnit package comment, not buried on a Wiki. + +

Kent Beck's Original Testing Framework

Kent Beck wrote this article, which is the source of SUnit.

Go back to Troy's Smalltalk Quickstart Notes page.

Changes

Latest

History