Joseph Pelrine: "Anytime we run code, we are testing". So in fact, we test code all the time - SUnit simply formalizes the process. Heh - the demos are all in VA, and Joseph felt compelled to announce that this shouldn't be taken as any kind of endorsement of one ST over another - all the code he's going to talk about is available for multiple dialects.

Smalltalkers should be proud that unit testing spread out of Smalltalk - it's another thing that we originated. The cross dialect versions of SUnit originated at a Camp Smalltalk in 2001. "This talk is about the interesting and cool stuff in SUnit that no one knows about or understands". JUnit - it's a big, fat version of SUnit - apparently, the elegance has been lost, and the other revs for other dialects have come from the JUnit version.

Now it's demo mode. Joseph has added descriptions to assertions (which can be logged) - allows you to see something about the failure without having to jump into the debugger. That would help when running a long set of tests. So - instead of:

self assert: someBooleanDescription.

We add:

self assert: someBooleanDescription description: 'Describe Failure Here'

Another thing is that it's often the case that - instead of just stopping on a test failure, we want to resume (perhaps other tests depend on this). So, Joseph has added a resumable test case that lets a failure get logged (see above), but doesn't stop.

"Unit tests are the only valid functional specification of a system"

Moving along - what about TestResources? In the simple case, we have #setUp and #tearDown (set a test up, tear it down). If you run a lot of tests, this could get expensive if you are using the same resource over and over again (say, opening an HTTP connection, opening a db connection, etc). A TestResource is a way of allowing such shared resources to move across multiple test cases. If the TestResource initialization doesn't work, none of the affected tests are run at all. Basically, it's an extended #setUp/#tearDown. It uses that same API as well. Like test cases, you derive new TestResources from the common superclass TestResource.

On the class side of the test case, you add a method like this:

resources
		^Array with: MyTestResourceHere 

Sometimes, you want to be able to use other tools with your testing - thus ExtensibleTestCase. The example - a simple test that compares two strings, failing if they don't match. What the extension does here is hook a text differator into the results - Joseph has used it to hook SUnit to ENVY Q/A and TestMentor. Nifty example - Joseph has a demo that hooks the "Debug" option to SmallLint instead. The hookup? An abstract class that specifies which methods are test methods (instead of the default, which picks up all the ones that begin with 'test'). Then, an override of the #performTest method to have it run the right test, and then apply SmallLint (or what have you) in case of failure - specifying which rules to apply.

This is actually one of the really cool things about SUnit - you can whack this sort of thing into the framework easily. Doing the equivalent kind of hacking in Java (or C#, et. al.) would be much more complicated.

Coming features:

• Remove TestRunner - better integration in all major dialects
• Integrate the description (first part) with hover help, so that moving the mouse over the list of failures will show the results w/o having to jump in
• Integration with a logging framework that Joseph has (Toothpick). Came out of someone wanting log4j like capability - Joseph decided to see what such a thing would look like if you did it right.
• Make TestErrors and TestFailures into new objects, instead of just exceptions.
• Integrate Continuations, allowing you to backtrack to the error state - note - that piece won't move to all dialects.
• What Joseph really wants to do is create a tight common core, and have other people configure specifically for each dialect.

Joseph has a download site for lots of the stuff he's talked about here, plus other stuff (like the Smalltalk Balloon graphics, Knights of the Square Bracket logo, etc). Look here.

Question: Why do so many people misunderstand/misuse TestResources? There hasn't been enough explanation - it's been passed by word of mouth and code reading. More needs to be done there - there's a manual at the link above.

Question: Two roles for helpers. One is for "heavy hitters" to do dialect specific work. Another one is for people to read/review the new TestResource manual.