Mobile/Fennec/GettingStartedWithTests: Difference between revisions

< Mobile‎ | Fennec
(Created page with '=Testing= Mozilla has several methods of creating and executing [https://developer.mozilla.org/en/Mozilla_automated_testing automated tests]. Fennec, as a web browser, can reuse …')
 
(→‎Tools: Removing obsolete tinderbox, mobile tree & browser-chrome references)
 
(2 intermediate revisions by one other user not shown)
Line 20: Line 20:
=Adding a Test=
=Adding a Test=
There is some [https://developer.mozilla.org/en/How_to_add_a_build-time_test general information] on building tests and adding them to the build. For the most part, you just add the test files and any supporting files to the [http://mxr.mozilla.org/mobile-browser/source/chrome/tests/ tests] folder and also add them to the [http://mxr.mozilla.org/mobile-browser/source/chrome/tests/Makefile.in#58 Makefile].
There is some [https://developer.mozilla.org/en/How_to_add_a_build-time_test general information] on building tests and adding them to the build. For the most part, you just add the test files and any supporting files to the [http://mxr.mozilla.org/mobile-browser/source/chrome/tests/ tests] folder and also add them to the [http://mxr.mozilla.org/mobile-browser/source/chrome/tests/Makefile.in#58 Makefile].
=Tools=
Once the tests has landed there are some automatic tools to ensure everything works fine on both desktop (bug|) and devices:
[http://tbpl.mozilla.org/ Tinderbox Pushlog] which you can turn into an App Tab that will glow when a test failed.

Latest revision as of 12:34, 8 March 2013

Testing

Mozilla has several methods of creating and executing automated tests. Fennec, as a web browser, can reuse many of the tests that run inside a <browser> element. These tests usually fall into mochitest and chrome tests.

The Fennec UI can be tested using browser-chrome tests. We have some browser-chrome tests here.

Goals

We want to automate as many UI functions as possible. At the same time, it should be relatively easy to add some unit tests for the code itself.

  • Add functional test that exercise the UI elements
  • Add unit tests that exercise the methods of JS objects
  • Favor breaking actions into small chunks, not a massive single test. For example, test adding a bookmark via star, adding via manager, deleteing via manager, editing via star, editing via manager - all as separate tests!
  • Duplicating steps in a test is not bad! Just make a helper function to handle repeated steps.
  • Try to start each test from the "I'm looking at the browser" state. Don't piggyback or chain tests together. If the first test fails the other tests won't be run.
  • Try to avoid using data stored in previous tests - it might not be there!

Coding a Test

Browser chrome tests are simply JavaScript files that are executed in a context that has some helper functions. The helper functions allow the test code to log failures and simulate mouse and keyboard actions.

The Fennec tests have two styles: A structured test case flow, borrowed from the Places tests and a simple global function flow. The structured flow is nice if your test file contains a lot of test cases. It allows you to cleanly break the tests apart. The simple flow is ... simple.

Adding a Test

There is some general information on building tests and adding them to the build. For the most part, you just add the test files and any supporting files to the tests folder and also add them to the Makefile.

Tools

Once the tests has landed there are some automatic tools to ensure everything works fine on both desktop (bug|) and devices:

Tinderbox Pushlog which you can turn into an App Tab that will glow when a test failed.