YUI UnitTesting is reintegrated in Launchpad's test suite. There are substantial changes that you need to know when working with JavaScript.
Note: We are waiting on rt #46284 to be completed. When pqm and buildbot
have the new test runner image, I will land a branch to enable YUI
unittest to be run by default.
Launchpad developer dependencies were updated a few days ago to require
html5browser. This library allows us to drive a modern browser from
python. It is based on webkitgtk. This is a html5/css3/es3 compatible
engine that is used by Chromium and Safari. You will not see a browser
while the test runs, but since this is a gtk library, xvfb is needed by
headless machines.
You can run all YUI unittests with
./bin/test -vvc --layer=YUI
The tests will complete in about 45 seconds.
The YUITestLayer extends FunctionalLayer. It requires that the tree is
built. It does not require an app server, Firefox, or windmill. The base
testcase does not poll or wait for the test to complete. The browser
connects to a the status-changed event which is sent by the YUI unittest
on complete. Assigning string that starts with '::::' will return the
string to the Python test.:
var handle_complete = function(data) {
window.status = '::::' + JSON.stringify(data);
};
Y.Test.Runner.on('complete', handle_complete);
See https://dev.launchpad.net/JavascriptUnitTesting for the full
example. Setting the window.status to a string without '::::' will not
affect the Python test.
The Python testcase expects a JSON encoded results. I think the approach
is fast and robust. Previously it waited for a DOM change then attempted
to parse the page to get the log. I discovered that YUI unittest will
fire the complete event *before* the log is rendered. This explains why
so many YUI tests fail on Jenkins, but do not *appear* to fail when we
view them in out browser. YUI tests that simulated events we often
affected by they issue.
I was surprised that many YUI unittests do not complete in under 5
seconds. There are two causes for this. Many test modules are composed
of many testcases; structural subscription tests for example could be
broken into several modules that complete quickly. I see a few tests
that are calling wait(). This looks scary. I do not know the reason for
this since the tests do not use a web server. Maybe the tests should
listen for a signal instead. I set the base Python unittest case to
increase the default browser timeout from 5 seconds to 30. This change
does not slow down the test runner. You may discover your test additions
cause a timeout failures.
--
__Curtis C. Hovey_________
http://launchpad.net/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
