1748
Comment:
|
3087
|
Deletions are marked like this. | Additions are marked like this. |
Line 6: | Line 6: |
== How is Windmill integrated? == | <<TableOfContents()>> == Using Windmill to Test Launchpad == === Setting up Windmill === Windmill is included in the Launchpad source tree. === Running the Launchpad Windmill test suite === |
Line 18: | Line 27: |
$ ./lp-windmill.py -t lib/canonical/launchpad/windmill/tests firefox http://launchpad.dev:8085 | $ ./lp-windmill.py test=lib/canonical/launchpad/windmill/tests firefox http://launchpad.dev:8085 |
Line 21: | Line 30: |
'''Note that it is not currently possible to run all the tests like that because of a bug/limitation in Windmill.''' You need to run each tests starting at the correct vhost. So for bugs tests, you'd use: {{{ $ ./lp-windmill.py test=lib/canonical/launchpad/windmill/tests/test_bugs firefox http://bugs.launchpad.dev:8085 }}} and for registry, you'd use: {{{ $ ./lp-windmill.py test=lib/canonical/launchpad/windmill/tests/test_registry firefox http://launchpad.dev:8085 }}} |
|
Line 29: | Line 50: |
And then fire off a windmill session using the normal command: | The Windmill driver script, `windmill.py`, is located under the `utilities/` directory. Using it, you can start an interactive shell to run tests without setting up and tearing down Launchpad repeatedly: |
Line 35: | Line 56: |
That way you can restart windmill, without having to wait for the Launchpad restart cycle. |
|
Line 41: | Line 60: |
=== How are the tests organized === | ==== How are the tests organized ==== |
Line 53: | Line 72: |
== Writing Tests == * Test the Happy Path, and one or two error paths * Edge cases are best pushed into the unit tests * Setup and teardown are expensive, so there will be a trend towards testing more per test * Prefer element ids to XPath for locating page elements * XPath makes your tests brittle and dependent on page structure |
|
Line 56: | Line 85: |
* [[http://www.slideshare.net/alexchaffee/fullstack-webapp-testing-with-selenium-and-rails|Full-stack webapp testing with Selenium and Rails]] - has a number of tips that apply to any automated testing framework ---- CategoryJavaScript CategoryTesting |
Windmill for JS Integration Tests
For integration testing that covers JS workflows, our tool of choice is Windmill.
Contents
Using Windmill to Test Launchpad
Setting up Windmill
Windmill is included in the Launchpad source tree.
Running the Launchpad Windmill test suite
There is a script called lp-windmill.py in the top-level directory. This is a wrapper around the windmill main script which starts a Launchpad server on port 8085 locally with a fresh database (including all of the standard tests sample data).
The windmill process is then fired off with the command line argument.
So if you want to run all the tests you'd typically use:
$ ./lp-windmill.py test=lib/canonical/launchpad/windmill/tests firefox http://launchpad.dev:8085
Note that it is not currently possible to run all the tests like that because of a bug/limitation in Windmill. You need to run each tests starting at the correct vhost. So for bugs tests, you'd use:
$ ./lp-windmill.py test=lib/canonical/launchpad/windmill/tests/test_bugs firefox http://bugs.launchpad.dev:8085
and for registry, you'd use:$ ./lp-windmill.py test=lib/canonical/launchpad/windmill/tests/test_registry firefox http://launchpad.dev:8085
For interactive test running and development, it's usually more convenient to run the Launchpad server separately:
$ ./lp-windmill.py --server-only
The Windmill driver script, windmill.py, is located under the utilities/ directory. Using it, you can start an interactive shell to run tests without setting up and tearing down Launchpad repeatedly:
$ ./utilities/windmill.py shell firefox http://launchpad.dev:8085
See the help page on the shell environment.
How are the tests organized
Tests written in python are rooted at lib/canonical/launchpad/windmill/tests.
Tests are divided by applications and then subdivided by workflows.
Tests using the JS API are in lib/canonical/launchpad/windmill/jstests.
Writing Tests
- Test the Happy Path, and one or two error paths
- Edge cases are best pushed into the unit tests
- Setup and teardown are expensive, so there will be a trend towards testing more per test
- Prefer element ids to XPath for locating page elements
- XPath makes your tests brittle and dependent on page structure
External resources
Full-stack webapp testing with Selenium and Rails - has a number of tips that apply to any automated testing framework