AMO:Developers/JavaScriptTesting: Difference between revisions
Jump to navigation
Jump to search
(→QUnit: Adding CommonJS) |
|||
Line 10: | Line 10: | ||
* Quick tests, easy to run during development | * 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 environment as close as possible to production, which is mainly the Firefox web browser | ||
** Really? What does that mean in practice (os/browser matrix)? A simpler goal is unit testing (pure JS environment) and integration testing (Fx or other). | |||
* A test suite that can run reliably in [https://hudson.mozilla.org/ CI] and deliver meaningful results | * A test suite that can run reliably in [https://hudson.mozilla.org/ CI] and deliver meaningful results | ||
* the ability to use a DOM since most features involve attaching behavior to the DOM | * the ability to use a DOM since most features involve attaching behavior to the DOM |
Revision as of 22:23, 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 run so here are some ideas about how we can make 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
- Really? What does that mean in practice (os/browser matrix)? A simpler goal is unit testing (pure JS environment) and integration testing (Fx or other).
- 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
- We want to create small integration tests that verify one or more widgets, not large functional tests that focus on website behavior (QA writes tests for that)
Test Runners
QUnit
- Pros
- CommonJS Unit Test compliant
- 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?)
- Proof of Concept
- You can clone this branch https://github.com/kumar303/zamboni/tree/new-addon-validator-609355 and open http://127.0.0.1:8000/en-US/firefox/qunit/
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