This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: SUnitToo Announced
Feed Title: Travis Griggs - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml
Feed Description: This TAG Line is Extra
OK, corny subject. As if I hadn't self aggrandized my alter-SUnit ego enough already. Vasilli Bykov has just published a new package called System-Announcements to the Open Repository and it even looks like he's beat me to the blog about them. A great read. And some great code. Mine is simply to offer a testimonial about this stuff.
When I got wind of this awhile back, around OOPSLA time, I wanted to try it out. SUnitToo used triggerEvents pretty heavily, and I wanted to get a taste of this new way. This idea's been talked about for a while, but no one's ever gone and done it to my knowledge.
Unfortunately, it's been a bit between the time of doing this but I'll do my best at recollection. Announcements are cool. In same ways they're "just like" triggerEvent:/change:update:. But they're not. The differences are subtle, but there.
The first thing I liked was the consistent metaphor throughout the code: subsciption, announcement, delivery, etc. I was able to quickly see how I needed to fit TestCase into this stuff.
Because these things are first class objects, built with real classes, there's no need of "constructEventsTriggered." Rename an Announcement and RB just gets the Rename right. Want to find where the event is triggered? Just browse references. No more need to always put all of an object's "events" in a "my events" protocol". And ambivalentEventChecking is gone. You can use mayAnnounce: to do something similar, but with the ability for the tools to just work with these things, suddenly that's not so important.
Reacting to Announcements is very much like dealing with Exceptions. And this is nice. With triggerEvents:, you had to do things like whenAny:send:to:. But with Announcements, I can do something like when: TestResult do: . That will catch Errors, and Passes, and Failures.
But, the fact that these things are real objects is just cool. At one point, it donned on me that I could actually keep the Announcement of a test result around for future reference. For example, when a Results sees any kind of Result, it uses a double dispatch which the Result subclass participates in to get the Result slotted into the right collection. One of the hard things was to reduce all of the test Results into Bags of results (e.g. 8 failures, 4 passes, etc). And then it donned on me that I didn't have to. I could just use the class of the result to condense them. And I could teach them (the classes) to respond to "testCaseIcon" and "testMethodIcon", rather than having to do dictionary lookups on symbols. And I could teach the result types to sort themselves by severity. This simplified a number of things, and made the code more OO than it was before. This is very nice, because an "announcer" can just use simple class references to announce simple things, but can attach "state" by using an instance of the object.
Pretty scatterbrained overview; the upshot was that I thought the Announcement stuff was just cool. Once I slid my approach for a couple of the issues, things just got easier. And that's as it should be. I will definitely switch our code from the mix of change:update: and triggerEvent: that it is now to use this stuff.
The SUnitToo (and ExtraRBForSUnitToo) trunk has been published as now using Announcements. I even published a branch of Announcement-Tests which uses the Announced version of SUnitToo to test the Announcments.
Previous Topic
