AMO:Developers/JavaScriptTesting: Difference between revisions
Jump to navigation
Jump to search
m (→Test Runners) |
mNo edit summary |
||
Line 14: | Line 14: | ||
=== Test Runners === | === Test Runners === | ||
==== [http://docs.jquery.com/Qunit 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 | |||
*** [https://github.com/kof/node-qunit/ QUnit in node.js] | |||
*** QUnit with Rhino + [https://github.com/thatcher/env-js env.js] (example in [http://pypi.python.org/pypi/NoseJS#running-javascript-tests NoseJS] and [https://github.com/eroh92/nosejs this fork]) | |||
*** [http://code.google.com/p/js-test-driver/wiki/QUnitAdapter Qunit for JsTestDriver] (Cannot do async testing) | |||
* Cons | |||
** Might be tricky to get working for CI. 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?) | |||
=== Mock Objects === | === Mock Objects === |
Revision as of 18:53, 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. 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?)
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