From: Nat Pryce <nat.pryce@...13media.com>
Date: 2002-03-21T00:43:03+09:00
Subject: Test::Unit GUI suggestion (was Re: Test::Unit GTk GUI)


From: "Nathaniel Talbott" <nathaniel@talbott.ws>
> I haven't used a GUI test runner for Ruby in ages, because there is not
> a safe way to load in changes to a test runner after it is already
> launched. This means the GUI has to be closed down and re-opened each
> time something is changed, which introduces too much friction in to the
> process for me; thus I've opted to use the console for now. Perhaps
> someday re-initialization will be possible, and then I'll be the first
> to go hunting for the green bar again.
>
> This means that the GUI runners are not as well cared for as the
> Console::TestRunner. Can they be used? Certainly. If they fill your
> need, use them. If more people seem to be using them (like right now),
> I'll commit more time to maintaining them.

How about Test::Unit only providing two TestRunner implementations which
both write to the console.  One generates human readable output that
concentrates on being easy to read and only shows the results of failures.
The other generates verbose output that is easy to parse, but describes the
result of each test that is excecuted.

GUI "test runners" would then spawn a Ruby process to execute the
machine-friendly test runner, parse the output from that process, and show
it graphically.  The spawning/parsing process could be wrapped into a class
with a similar API to the existing test runner classes.  By spawning a
separate Ruby process, each test run would start with a clean set of
classes.  An additional advantage of this approach is that Test::Unit suites
could more easily be integrated into non-Ruby APIs such as Visual Studio or
Eclipse.

Cheers,
            Nat.

________________________________
Dr. Nathaniel Pryce
B13media Ltd.
40-41 Whiskin St, London, EC1R 0BP, UK
http://www.b13media.com