AMO:Developers/JavaScriptTesting: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 11: Line 11:
* 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).
** 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).
** If a pure JS environment was "pretty close" to production then that would be fine.  A problematic scenario would be where something worked in the tests but not in production (the browser has its quirks!) --[[User:Kumar303|Kumar303]] 08:45, 16 November 2010 (PST)
* 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 16:45, 16 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).
    • If a pure JS environment was "pretty close" to production then that would be fine. A problematic scenario would be where something worked in the tests but not in production (the browser has its quirks!) --Kumar303 08:45, 16 November 2010 (PST)
  • 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)
  • User interface tests that do not rely on a server. That is, no actual Ajax requests just mock requests (if needed).

Test Runners

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