Having now got Selenium running I'm looking at some unit testing stuff.
I've looked at the test runner at
http://qooxdoo.org/documentation/0.7/frame_apps_testrunner which seems
quite good.
There are one or two problems which I've reported (issue 821, 822)
I've been thinking about the way we could use Selenium to run unit tests,
automating the whole process. The testRunner app is great but it has to
be run manually.
We can evaluate arbitrary code using the Selenium assertEval command. I
did a short test script for a tricky helper class I wrote yesterday, and
Selenium can run it and test the result while testing our application:
tr>
<td>assertEval</td>
<td>var rm = new window.abling.util.CRangeManager();
rm.AddRange(1,5,"1","5");rm.AddRange(6,10,"6"
;,"10");String(rm);</td>
<td>1-10</td>
</tr>
Output:
[info] Executing: |assertEval | var rm = new
window.abling.util.CRangeManager();
rm.AddRange(1,5,"1","5");rm.AddRange(6,10,"6","10");String(rm); | 1-10 |
One advantage of this is that we could add some simple methods to our
classes to enable the current state to be inspected while running our
whole application test. Therefore in addition to testing what's on the
screen we can verify other information internal to the application.
But also we can then build up and run arbitrary unit tests created in our
Python environment for running Selenium tests.
However that separates the unit tests from the code which isn't very good,
and it would be difficult to debug the unit tests.
If the test runner tests were incorporated in a "make source" build
(perhaps with "make source-test") then we could invoke them from a source
version using injected code from Selenium; alternatively if they were
included in a "make build-test" version as well then we could test the
build compilation (probably quite important given the compression that is
done).
A rough outline of what is needed is:
- test runner testcases and basic stuff incorporated into main qooxdoo
code tree.
- normal source and build targets exclude any unit testing code.
- additional make targets "source-test" and "build-test" which include
the unit testing code but don't invoke it. The user could add an
arbitrary interface to run them from their UI, using qooxdoo variants.
- add a standard API for invoking the test cases from Selenium more
easily.
- "make test-source" and "make test" remain as they are to create the
testRunner application for manual testing. As above, Selenium API created
for running any individual test, or group of tests so that can be
automated as well (maybe just the same as when using the application).
What are your thoughts on this, Thomas?
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
