From efa85ca0809d109f377adef17fa209d6c81e4e7f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thibault=20Delavall=C3=A9e?= Date: Tue, 17 Apr 2012 11:22:05 +0200 Subject: [REF] Added first chapter from dev book: getting started. Rewrote the installation guide. bzr revid: tde@openerp.com-20120417092205-5mfvukv35qysj6h6 --- doc/test-framework.rst | 100 ------------------------------------------------- 1 file changed, 100 deletions(-) delete mode 100644 doc/test-framework.rst (limited to 'doc/test-framework.rst') diff --git a/doc/test-framework.rst b/doc/test-framework.rst deleted file mode 100644 index 56951b1a8e1..00000000000 --- a/doc/test-framework.rst +++ /dev/null @@ -1,100 +0,0 @@ -.. _test-framework: - -Test framework -============== - -In addition to the YAML-based tests, OpenERP uses the unittest2_ testing -framework to test both the core ``openerp`` package and its addons. For the -core and each addons, tests are divided between three (overlapping) sets: - -1. A test suite that comprises all the tests that can be run right after the - addons is installed (or, for the core, right after a database is created). - That suite is called ``fast_suite`` and must contain only tests that can be run - frequently. Actually most of the tests should be considered fast enough to be - included in that ``fast_suite`` list and only tests that take a long time to run - (e.g. more than a minute) should not be listed. Those long tests should come up - pretty rarely. - -2. A test suite called ``checks`` provides sanity checks. These tests are - invariants that must be full-filled at any time. They are expected to always - pass: obviously they must pass right after the module is installed (i.e. just - like the ``fast_suite`` tests), but they must also pass after any other module is - installed, after a migration, or even after the database was put in production - for a few months. - -3. The third suite is made of all the tests: those provided by the two above - suites, but also tests that are not explicitely listed in ``fast_suite`` or - ``checks``. They are not explicitely listed anywhere and are discovered - automatically. - -As the sanity checks provide stronger guarantees about the code and database -structure, new tests must be added to the ``checks`` suite whenever it is -possible. Said with other words: one should try to avoid writing tests that -assume a freshly installed/unaltered module or database. - -It is possible to have tests that are not listed in ``fast_suite`` or -``checks``. This is useful if a test takes a lot of time. By default, when -using the testing infrastructure, tests should run fast enough so that people -can use them frequently. One can also use that possiblity for tests that -require some complex setup before they can be successfuly run. - -As a rule of thumb when writing a new test, try to add it to the ``checks`` -suite. If it really needs that the module it belongs to is freshly installed, -add it to ``fast_suite``. Finally, if it can not be run in an acceptable time -frame, don't add it to any explicit list. - -Writing tests -------------- - -The tests must be developed under ``.tests`` (or ``openerp.tests`` -for the core). For instance, with respect to the tests, a module ``foo`` -should be organized as follow:: - - foo/ - __init__.py # does not import .tests - tests/ - __init__.py # import some of the tests sub-modules, and - # list them in fast_suite or checks - test_bar.py # contains unittest2 classes - test_baz.py # idem - ... and so on ... - -The two explicit lists of tests are thus the variables ``foo.tests.fast_suite`` -and ``foo.tests.checks``. As an example, you can take a look at the -``openerp.tests`` module (which follows exactly the same conventions even if it -is not an addons). - -Note that the ``fast_suite`` and ``checks`` variables are really lists of -module objects. They could be directly unittest2 suite objects if necessary in -the future. - -Running the tests ------------------ - -To run the tests (see :ref:`above ` to learn how tests are -organized), the simplest way is to use the ``oe`` command (provided by the -``openerp-command`` project). - -:: - - > oe run-tests # will run all the fast_suite tests - > oe run-tests -m openerp # will run all the fast_suite tests defined in `openerp.tests` - > oe run-tests -m sale # will run all the fast_suite tests defined in `openerp.addons.sale.tests` - > oe run-tests -m foo.test_bar # will run the tests defined in `openerp.addons.foo.tests.test_bar` - -In addition to the above possibilities, when invoked with a non-existing module -(or module.sub-module) name, oe will reply with a list of available test -sub-modules. - -Depending on the unittest2_ class that is used to write the tests (see -``openerp.tests.common`` for some helper classes that you can re-use), a database -may be created before the test is run, and the module providing the test will -be installed on that database. - -Because creating a database, installing modules, and then dropping it is -expensive, it is possible to interleave the run of the ``fast_suite`` tests -with the initialization of a new database: the dabase is created, and after -each requested module is installed, its fast_suite tests are run. The database -is thus created and dropped (and the modules installed) only once. - -.. _unittest2: http://pypi.python.org/pypi/unittest2 -- cgit v1.2.3