> JSUnit relies on exceptions for problem reporting but if everything goes
> through OK it just returns. I'm not sure why the same technique can't be
> used by the Selenium test layer so that any failure exceptions are caught
> and documented as failures in the return information.
Oh yes, that's fine, and I wrote as much. I just wasn't sure if that
would be enough for you, or whether you wanted more than just a
pass/fail outcome from the test (like a real return value like 3 or "a
string").
> It would mean some
> code in qooxdoo to run the tests so we have:
>
> Selenium command: qxRunTest - argument is regular expression that
> matches tests
> Calls via SRC & eval to:
>
Well, you don't need a dedicated command if you use the Selenium
'getEval()', like in
Selenium.getEval('application.testsuite.runTests("regexp")')
> Qooxdoo function qx.dev.unit.Selenium.getInstance().runTest (or
>
I'm not sure about this making it into the framework. I'd rather thought
it could be part of the Simulator project. Will need to talk to the guys
about that ... Most probably we should start in Simulator, and maybe
move the code later if that seems appropriate.
> similar) to find and run appropriate tests catching exceptions etc
> as needed, marshalling results
>
Yep, no problem here.
> Values returned to Selenium for logging
>
You mean "Selenium" as in your Selenium client driver programm (e.g.
Python), not "Selenium" as in Selenium Core, right?!
> The qooxdoo function would be included as standard in "make source" but
> would normally be excluded in "make build". "make build-test" would
> include it so that tests could be run on a build version of the code.
>
Again, I'm not so sure about that. If we start as part of the Simulator,
you would use the normal contrib mechanism to draw it into your app, and
then maybe add some Makefile directives to control inclusion of the test
classes in your code. I wouldn't want to invest much time in the old
build system anyway.
> I don't see any way for qxRunTest to know which functions are available
> to run, therefore carrying out tests which match its argument, unless
> there is a function or class in the qooxdoo code which keeps a register
> of the available functions; or indeed searches for them dynamically. Once
>
Yes, the JSunit way is by convention: search methods starting with
"test*". This as default, together with the regexp thing, should be
enough, so we won't need a register.
>> Of course it seems possible to combine both protocols in the same
>> tests, these checking whether they are run in "Testrunner-" or
>> "Seleniumrunner-mode".
>>
>
> I would really like to avoid that!
>
Then we're two :).
Thomas
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
