> Yes. Remote HTTP requests from Javascript were an aside until people > realised how powerful they were :-) >
Ok, I get it ... :). > Selenium is about automating testing of an application, most of which is > Javascript. Ultimately that javascript has a result in that tags and > images and widgets are positioned in the DOM, but in some cases you might > want to test the Javascript in ways which would be tricky with > manipulation of the application. That's where automated unit testing of > the Javascript comes in. > Ok, so the baseline of your proposal is to have Selenium invoke Javascript code and return the result value(s). We assume an SRC client script provides the invoking code (through assertEval and the likes), and will also receive and evaluate the result value(s). That means Selenium takes more and more the part of sort of an RPC infrastructure, and is rather concerned with passing values to and fro, but with little logic involved. Am I getting you right so far? >> Another point: In my understanding, unit test do *not* return a >> value. They either succeed silently or throw an exception. I think >> JsUnit works this way, and we designed our unit test protocol >> corresponingly (We even supported running TestRunner tests from a >> JsUnit framework). If you start adding return values to your tests >> you're leaving the confines of this protol and are entering a >> completely new testing realm. >> > > Totally agreed. I was using return values because I was calling functions > under test directly. > I will have to think (and discuss within the team) if we want to detour in such a way, and if we can support both approaches. > So the wrapper function can simply fail (in the Selenium sense) and log > an error. There might be some work required here to ensure that we can > continue running tests and show all the failures rather than just > stopping at the first hurdle. I don't know if that's possible in > Selenium. > I think this should not be a problem. If you want to deploy Selenium's assert mechanisms, you could go for the 'verify*' assertions, which will continue the test. If you use Selenium only to pipe values to and fro, you're on your own and can do in your test script whatever you please. I presume you are also not very interested in the Selenium log, when you can have all the evaluation (and therefore logging) in the client driver, right?! 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
