Confirmed users
324
edits
AMO:Developers/JavaScriptTesting: Difference between revisions
no edit summary
No edit summary |
|||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
---- | |||
'''UPDATE: This was a brainstorming page that led to the creation of''' [https://github.com/kumar303/jstestnet JS TestNet] | |||
---- | |||
The [http://github.com/jbalogh/zamboni 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. | The [http://github.com/jbalogh/zamboni 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. | ||
| Line 11: | Line 18: | ||
* 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 | ||
* 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) | * 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 === | === Test Runners === | ||
| Line 36: | Line 45: | ||
* Proof of Concept | * 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/ | ** 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/ | ||
*** At the moment you'll need to pip install https://github.com/kumar303/django-qunit/ | |||
==== [http://ianb.github.com/doctestjs/ doctest.js] ==== | ==== [http://ianb.github.com/doctestjs/ doctest.js] ==== | ||
| Line 46: | Line 56: | ||
* Cons | * Cons | ||
** Might be tricky to integrate into CI | ** Might be tricky to integrate into CI | ||
==== [https://github.com/caolan/nodeunit nodeunit] ==== | |||
* Pros | |||
** can take advantage of the node.js world (like require statements!) | |||
** nice command line output | |||
** easy for CI | |||
* Cons | |||
** Needs a mock dom (like [https://github.com/tmpvar/jsdom jsdom]?) | |||
** might take some fiddling to get things working outside of the Zamboni template stack (loading JS libraries, etc) | |||
** will it be similar enough to production? (i.e. Firefox) | |||
* Notes | |||
** see also [https://github.com/kof/node-qunit/ node-qunit] (above) | |||
=== Mock Objects === | === Mock Objects === | ||