On Dec 19, 2003, at 1:35 AM, Frank Shearar wrote:

> I was thinking about this 1-1 mapping being painful this morning. 
> However,
> I don't think I use BrowseUnit in quite the usual way. I typically have
> two Browsers open, one with the production code I'm working on and one
> with the tests for that code. In the test code browser, I use the 
> BrowseUnit
> buttons to run the tests for the message or class I'm working on - I 
> don't
> use them to create the test classes or messages. While I usually end up
> with one test class for one production class, I usually have scads of 
> test
> messages for any particular message (depending on the complexity of the
> message - some of the transaction state changes in SIP (RFC 3261) can 
> cause
> a lot of things to be tested - far too many for just one test message).

Yup, that's pretty much how I work, although I use Ned's Enhanced 
TestRunner instead of BrowseUnit.  I probably should have mentioned 
that I'm not entirely against having test cases that only test one 
production class. I just don't want to be forced into that pattern, by 
tools or convention.

>> PS. I'm partial Kazuki Minamitani's TestBrowser, although it hasn't
>> worked well in recent versions of Squeak. I'd love to see
>> this kind of
>> tool further developed.
>
> Yes, TestBrowser also rocks. And since I started using it the other 
> day,
> well,
> I'm finding that it's actually a bit handier to use than BrowseUnit 
> because
> I can run the tests for an entire category as easily as testing one 
> class or
> message.
>
> However, I stick by my guns on the slint button BrowseUnit provides :)
>
> Although, if TestBrowser had a slint button on it that ran slint in 
> another
> process like BrowseUnit...

Agreed. I like SLint, although I haven't found a way to use it in my 
day to day programming.

Colin