diff --git a/content/developer/reference/backend/testing.rst b/content/developer/reference/backend/testing.rst index d3458dc3d..10bf74372 100644 --- a/content/developer/reference/backend/testing.rst +++ b/content/developer/reference/backend/testing.rst @@ -281,252 +281,17 @@ Testing JS code Testing a complex system is an important safeguard to prevent regressions and to guarantee that some basic functionality still works. Since Odoo has a non trivial -codebase in Javascript, it is necessary to test it. In this section, we will -discuss the practice of testing JS code in isolation: these tests stay in the -browser, and are not supposed to reach the server. +codebase in Javascript, it is necessary to test it. -.. _reference/testing/qunit: +See the :doc:`Unit testing <../frontend/unit_testing>` to learn about the +various aspect of the front-end testing framework, or jump directly to one of the +sub-sections: -Qunit test suite ----------------- +- :doc:`Hoot <../frontend/unit_testing/hoot>` -The Odoo framework uses the QUnit_ library testing framework as a test runner. -QUnit defines the concepts of *tests* and *modules* (a set of related tests), -and gives us a web based interface to execute the tests. +- :doc:`Web test helpers <../frontend/unit_testing/web_helpers>` -For example, here is what a pyUtils test could look like: - -.. code-block:: javascript - - QUnit.module('py_utils'); - - QUnit.test('simple arithmetic', function (assert) { - assert.expect(2); - - var result = pyUtils.py_eval("1 + 2"); - assert.strictEqual(result, 3, "should properly evaluate sum"); - result = pyUtils.py_eval("42 % 5"); - assert.strictEqual(result, 2, "should properly evaluate modulo operator"); - }); - -The main way to run the test suite is to have a running Odoo server, then -navigate a web browser to ``/web/tests``. The test suite will then be executed -by the web browser Javascript engine. - -.. image:: testing/tests.png - :align: center - -The web UI has many useful features: it can run only some submodules, or -filter tests that match a string. It can show every assertions, failed or passed, -rerun specific tests, ... - -.. warning:: - - While the test suite is running, make sure that: - - - your browser window is focused, - - it is not zoomed in/out. It needs to have exactly 100% zoom level. - - If this is not the case, some tests will fail, without a proper explanation. - -Testing Infrastructure ----------------------- - -Here is a high level overview of the most important parts of the testing -infrastructure: - -- there is an asset bundle named `web.qunit_suite`_. This bundle contains - the main code (assets common + assets backend), some libraries, the QUnit test - runner and the test bundles listed below. - -- a bundle named `web.tests_assets`_ includes most of the assets and utils required - by the test suite: custom QUnit asserts, test helpers, lazy loaded assets, etc. - -- another asset bundle, `web.qunit_suite_tests`_, contains all the test scripts. - This is typically where the test files are added to the suite. - -- there is a `controller`_ in web, mapped to the route */web/tests*. This controller - simply renders the *web.qunit_suite* template. - -- to execute the tests, one can simply point its browser to the route */web/tests*. - In that case, the browser will download all assets, and QUnit will take over. - -- there is some code in `qunit_config.js`_ which logs in the console some - information when a test passes or fails. - -- we want the runbot to also run these tests, so there is a test (in `test_js.py`_) - which simply spawns a browser and points it to the *web/tests* url. Note that - the browser_js method spawns a Chrome headless instance. - - -Modularity and testing ----------------------- - -With the way Odoo is designed, any addon can modify the behaviour of other parts -of the system. For example, the *voip* addon can modify the *FieldPhone* widget -to use extra features. This is not really good from the perspective of the -testing system, since this means that a test in the addon web will fail whenever -the voip addon is installed (note that the runbot runs the tests with all addons -installed). - -At the same time, our testing system is good, because it can detect whenever -another module breaks some core functionality. There is no complete solution to -this issue. For now, we solve this on a case by case basis. - -Usually, it is not a good idea to modify some other behaviour. For our voip -example, it is certainly cleaner to add a new *FieldVOIPPhone* widget and -modify the few views that needs it. This way, the *FieldPhone* widget is not -impacted, and both can be tested. - -Adding a new test case ----------------------- - -Let us assume that we are maintaining an addon *my_addon*, and that we -want to add a test for some javascript code (for example, some utility function -myFunction, located in *my_addon.utils*). The process to add a new test case is -the following: - -1. create a new file *my_addon/static/tests/utils_tests.js*. This file contains the basic code to - add a QUnit module *my_addon > utils*. - - .. code-block:: javascript - - odoo.define('my_addon.utils_tests', function (require) { - "use strict"; - - var utils = require('my_addon.utils'); - - QUnit.module('my_addon', {}, function () { - - QUnit.module('utils'); - - }); - }); - - -2. In *my_addon/assets.xml*, add the file to the main test assets: - - .. code-block:: xml - - - -