mikeal at osafoundation.org
Mon Aug 27 15:50:09 PDT 2007
> The overlap seems to be in the need for a reporting mechanism for
> tests that aren't passed over from the service. And obviously the
> native JS tests for Windmill require extra work to define an API.
> Is the work required for JSUnit integration simply a prerequisite
> for native JS tests -- or is there extra work that would be needed
> specifically for the Cosmo JSUnit tests? If there's no extra work,
> then yeah, it makes sense to knock it all out in one fell swoop.
> Otherwise, if there are discussions for the JSUnit work that could
> drag on for awhile, I'd really like to lay the groundwork first,
> and then do the work for JS tests and JSUnit integration on
> separate tracks.
Well, any test authoring library needs a test framework. The JSUnit
framework seems like as good a one as any so we might as well just
use it since it's already defined. The only "extra" work would be
implementing all the assertBlah functions in the jum object to call
the windmill reporting mechanism discussed earlier, that way any
existing JSUnit tests would be able to run. The functions in the
jum.controller namespace shouldn't need to be wrapped in jum.assert
statements by a test author, they should call all the reporting
mechanisms on their own.
If you want to start on a wiki page proposal for this work that would
be awesome. You don't need to define all the changes you'll make to
the IDE "guts", just outline the public API you'll be writing for
test authors and we can work together on defining all the service
calls and command line options you'll need.
More information about the Windmill-dev