On 4/19/06, David Wheeler <[EMAIL PROTECTED]> wrote: > On Apr 19, 2006, at 12:14, Fergal Daly wrote: > > > One other reason (that I didn't see mentioned) is that objects imply > > that the harness and tests are in the same process which means that > > the tests can corrupt the harness and that the harness can fail to > > report if the test process dies, > > Well, the harness can be corrupted by bad output, too (do something > like this in a test to see what I mean: > > print STDOUT "ok - Ha ha ha!\n"; > > ). But in the JavaScript port, tests run in a browser, and there's no > such thing a separate processes, so I had no choice there. So I > decided to do both things: Test.Harness uses the objects it collects > from Test.Builder to summarize test pasess, failures, what to output > to the browser, and what not. But Test.Builder also sends all output > to a series of appropriate function calls (which in the browser all > go to the same place), so the test can run without the harness and > display results, and so that some other harness could potentially > scrape the output to summarize the results.
Yes, in the context of javascript testing, there's no choice but, for example, I have used DUnit (Delphi) and it has a nice GUI test runner but it's very annoying to have your test launching and result display program wedge, crash or silently disappear because of a problem with the module you're testing, F
