> > 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").
Pass/fail is fine with me, combined with log capture. With failure, the
error message will be sent as well.
> > 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")')
OK, but it seems to me that it would be quite easy to add a simple
qxRunTest function to the IDE and language interfaces. Makes it more
"official".
> > 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.
Fair enough.
> > 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?!
Yes.
> 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.
Don't invest in the old build system. I'm not up to speed on the
mechanisms in the new build system. It sounds like they will be flexible
enough to cope with various strategies. As long as it's easy to add or
remove the code.
> 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.
OK. Would that work with aggressive optimisation of method names in a
hypothetical future build version?
Hugh
-------------------------------------------------------------------------
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
