Enhancing Sunit

This page is intended for discussion of possible enhancements/fixes to SUnit (see also SmalltalkUnit)

What changes are in SUnit 2? -- GeneralPublic?

Official (means in sync with other official ports and updated to the latest version of the respective SmalltalkProgrammingEnvironment) ports to

in addition to VisualWorks and VisualSmalltalk, a simple user interface (TestRunner) and a new maintainer/steward (me) -- DanielEnting

The major changes are new messages for checking for expected results. In addition to #should: aBlock and #shouldnt: aBlock, the framework now supports #assert: aBoolean and #deny: aBoolean. The extra flexibility of the block was seldom used. You should write new code with #assert: and #deny:.

The other change that may break some tests is the removal of the "name" instance variable from TestSuite and the class method #named: aString. You can put these back in if you miss them, but again, they were seldom used to advantage in the tests I saw. -- KentBeck

TestRunner is a brutally simple interface. You might want to extend it to show a progress bar while the tests are running, to select a subset of the tests to run (a tree view can be good for this), or to record and display the exception causing a test to fail.

Another clever trick is to distinguish between the debugging of errors and failures. Errors you generally just want to let run until they blow up (the current behavior). Failures, however, you would generally like to debug by setting a breakpoint at the beginning of the test method. -- KentBeck

There will be NO SUnit 2.5 release whenever. It would have had:

SUnit is being re-structured as part of the CampSmalltalk ANSI work. The design is simple - separate the GUI from the model. Having a dialect-independent ANSI core will allow people to build GUI's or skins to their heart's content. - JosephPelrine. "Samuel S. Shuster" <sames@interaccess.com> on behalf of the ANSI Group of Camp Snmalltalk has taken over responsibility for SUnit. -- DanielEnting

We have developed a test runner GUI which allows jumping directly into the debugger or browser after selecting an error or failure. This is very useful especially with non-obvious bugs. But maybe that's not possible for all Smalltalk IDEs. -- john.link@gmx.net

I don't understand the above comment. The TestRunner of SUnit 2 already has a listbox with all failures and errors of the last run. Upon selection [in the listbox] a debugger is opened on the offending code. That works on all supported platforms. -- DanielEnting

#valueOf:shouldRaise: - I've added that to my local version. In fact what I more commonly need is #valueOf:shouldRaise:tag:. I have also added #errorOf: aBlock which returns the entire error object; mainly as a helper for the other two but I don't see why it shouldn't be publicly available. Client code can then make arbitrary checks on the error.

I added this because I am doing some web server stuff and I am using the tag to pass HTTP response codes (like #fileNotFound) back. It is important to the apps correctness that the errors and tags be checked. I think in general, error handling is an area that needs to be verified carefully. -- DaveHarris

What aspect of error handling do you want to verify carefully? SUnit is a small and simple framework that invites everybody to extend it. IHMO these extensions shouldn't necessarily be integrated in the base release so SUnit stays small and simple. -- DanielEnting

Sometimes a single bug makes a dozen overlapping tests fail. Then I have to figure out which is the simplest test which demonstrates the failure, and work on that one first. I have wondered whether there is some way to indicate to the test harness which tests are (nominally) dependent on which other tests so that the ones least likely to fail can be listed first. I can't see a neat way to do this myself, though. -- DaveHarris

This feature is also something I have wished for. -- MarkSchwenk

What do people think about subclassing TestCases? I have a hierarchy of domain classes such that each subclass ought to pass every test of its base class. It seems natural to express this by having the test case for the subclass derive from the test case of the base class.

That doesn't currently work with SUnit. Only test methods declared directly in the derived test case get invoked; it forgets about inherited ones.

Also, if you are doing this kind of thing you sometimes get abstract domain classes which can't be tested directly; only their subclasses can be instantiated and tested. It follows that there will be a test case which will be abstract - it exists only to hold test methods that apply to all the subclasses. SUnit doesn't have any support for this either.

I am just starting to use UnitTests and SUnit. I get the feeling I am pushing it in ways it doesn't expect. Am I missing the point somehow? I have about 13 TestCase subclasses, which is already enough that they need to be organized somehow to make them manageable, and a class hierarchy seemed a natural way to enforce Liskov Substitutability. Do people normally cut & paste test methods between TestCase classes? -- DaveHarris

See also the Camp Smalltalk SUnit Cool Tools page [http://wiki.cs.uiuc.edu/CampSmalltalk/SUnit+Cool+Tools+And+Add-Ons]

EditText of this page (last edited October 26, 2013) or FindPage with title or text search