A while back, Sherry Michaels (who I have the privelege of working with at Cincom) did some interesting work to try and reconcile the disparity between SUnitToo(ls) and the semi-large set of tests already written for VisualWorks. What follows is Sherry in "Guest Blogger" mode, writing about this cool work.

I much prefer the SUnitToo UI for running tests. Its semi-persistent test state and the visual feedback it gives are clear advantages in the development process. In fact, they were so important to me that I wheedled Alan into letting me convert the WebTolkit test suite to SUnitToo last year when I was fixing up the WebToolkit configuration model.

I've moved on to more comprehensive refactoring in the Tools/UI arena these days, and I often need to run the correspondingly more comprehensive basic VisualWorks test suites which are written using the original SUnit hierarchy. Still I'm spoiled by the SUnitToo test tools, and I really wanted to use them again. I discovered that if I was careful about running tests that make use of the original SUnit hierarchy rules concerning what is an abstract test and when selectors are inherited, I could use the SUnitToo Class menu item to convert a class to use SUnitToo and run it with those tools. So I started there, but soon found that I needed to occasionally add to or update the set of tests I was running.

About the third time I managed to publish the test suite with the TestCase superclass still in the SUnitToo hierarchy, I started to consider how the two frameworks might be reconciled. My previous discussions with Travis, during my WebToolkit retrofit, about his motivations in developing the SUnitToo framework had convinced me his minimalist approach was correct. I also knew that SUnitToo and its tools make use of VisualWorks Announcements to instrument much of the behavior that I was interested in using. Converging the two code bases was not an option.

I eventually took the approach of building a "bridge" between the two hierarchies. This has worked well enough for me and a few others that I was encouraged recently to put it into the public repository -- SUnit-Bridge2SU2. The mechanism involves replacing TestCase and TestResource in the XProgramming.SUnit namespace with identically named classes that inherit from their counterparts in the SUnit (SUnitToo framework) namespace. We can't just load the package containing the bridge classes because they need to be stripped versions which know just enough to be able to handle the hierarchy rules expected by the original tests, and otherwise use their SUnitToo superclass to run the tests. Overriding the class doesn't delete the undesired original methods. So, with a little magic from the RefactoringBrowser, the original XProgramming.SUnit classes are renamed and bridge classes are inserted in their place when the package is loaded into the image.

If you load the SUnit-Bridge2SU2 package before you load your test suites, only this package and the original SUnit package will contain changes. You probably don't care because you're not likely to be publishing either of these anyway. Your test packages will not be marked dirty unless you have actually made real changes. If you forget to load the bridge first, your tests will be marked dirty (we actually did replace the TestCase and TestResource superclass, after all). But these changes resolve as "no conflict" changes and reconciling your test packages against the repository again will reset the tick marks. Now you can run your existing standard SUnit tests using the SUnitToo tools and enjoy the visual feedback, the semi-persistent state and additional browsers to manage the failed tests.

Pretty cool, huh? Sherry's not much a toot her own horn type of person. So I'll chime in by tooting it for her.