AMO:Developers/JavaScriptTesting: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 24: Line 24:
*** has several adapters for the command line
*** has several adapters for the command line
**** [https://github.com/kof/node-qunit/ QUnit in node.js]
**** [https://github.com/kof/node-qunit/ QUnit in node.js]
**** QUnit with Rhino (some work on this in [http://pypi.python.org/pypi/NoseJS#running-javascript-tests NoseJS])
**** 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)
**** [http://code.google.com/p/js-test-driver/wiki/QUnitAdapter Qunit for JsTestDriver] (Cannot do async testing)
** Cons
** Cons

Revision as of 18:51, 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
    • 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