AMO:Developers/JavaScriptTesting: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
No edit summary |
||
| Line 28: | Line 28: | ||
*** [http://code.google.com/p/js-test-driver/wiki/QUnitAdapter Qunit for JsTestDriver] (Cannot do async testing) | *** [http://code.google.com/p/js-test-driver/wiki/QUnitAdapter Qunit for JsTestDriver] (Cannot do async testing) | ||
* Cons | * Cons | ||
** Might be tricky to get working for CI. | ** Might be tricky to get working for CI. We could load a single webpage in a web browser VM though and use builtin hooks to get test results | ||
** All user events need to be simulated by triggering the event or otherwise. | ** All user events need to be simulated by triggering the event or otherwise. | ||
** does not fit seamlessly into the current test suite (but maybe with NoseJS?) | ** does not fit seamlessly into the current test suite (but maybe with NoseJS?) | ||
==== [http://ianb.github.com/doctestjs/ doctest.js] ==== | |||
* Pros | |||
** Tests are in a more readable format | |||
** Doubles as documentation | |||
** some builtin utilities for async testing (like wait()) | |||
** runs in a browser, like production | |||
* Cons | |||
** Might be tricky to integrate into CI | |||
=== Mock Objects === | === Mock Objects === | ||
Revision as of 18:58, 15 November 2010
The Zamboni Django app has quite a bit of JavaScript now for features on the site. We currently don't have any automated tests to develop on this code base so here are some ideas about how we can add a test suite.
Why?
- Tests help to refactor existing code
- Tests make it easier to upgrade libraries like jQuery or external plugins
- It's easier to work on another developer's features without fear when there are tests
- A good testing environment helps to simulate errors and timeouts that can be hard or impossible to test manually
What Do We Want?
- Quick tests, easy to run during development
- A test environment as close as possible to production, which is mainly the Firefox web browser
- A test suite that can run reliably in CI and deliver meaningful results
- the ability to use a DOM since most features involve attaching behavior to the DOM
Test Runners
QUnit
- Pros
- popular framework, well supported
- very simple and easy to write tests with
- Runs primarily in a web browser like production
- Can provide visual feedback if necessary (useful for development)
- uses a real DOM
- since tests are written in HTML, Zamboni template logic can be reused in some cases
- has several adapters for the command line
- QUnit in node.js
- QUnit with Rhino + env.js (example in NoseJS and this fork)
- Qunit for JsTestDriver (Cannot do async testing)
- Cons
- Might be tricky to get working for CI. We could load a single webpage in a web browser VM though and use builtin hooks to get test results
- All user events need to be simulated by triggering the event or otherwise.
- does not fit seamlessly into the current test suite (but maybe with NoseJS?)
doctest.js
- Pros
- Tests are in a more readable format
- Doubles as documentation
- some builtin utilities for async testing (like wait())
- runs in a browser, like production
- Cons
- Might be tricky to integrate into CI
Mock Objects
To simulate errors and not depend on a web server, it makes sense to mock out Ajax requests.
- The mockjax jQuery plugin works well for this