Skip to content

Commit c6f61ec

Browse files
committed
[IMP] tests: document testing framework
Add details about the test classes for upgrades.
1 parent fd578e3 commit c6f61ec

File tree

1 file changed

+189
-34
lines changed

1 file changed

+189
-34
lines changed

src/testing.py

Lines changed: 189 additions & 34 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,110 @@
1+
r"""
2+
There are two main classes used testing during the upgrade.
3+
4+
* :class:`~odoo.upgrade.testing.UpgradeCase` for testing upgrade scripts,
5+
* :class:`~odoo.upgrade.testing.UpgradeCase` for testing invariants across versions.
6+
7+
Subclasses must implement:
8+
9+
* For ``UpgradeCase``:
10+
11+
- ``prepare`` method: prepare data before upgrade,
12+
- ``check`` method: check data was correctly upgraded.
13+
14+
* For ``IntegrityCase``:
15+
16+
- ``invariant`` method: compute an invariant to check.
17+
18+
Put your test classes in a ``tests`` Python module (folder) in any of the folders
19+
containing the upgrade scripts of your modules. The script containing your tests should
20+
have a `test_` prefix. The ``tests`` module must contain an ``__init__.py`` file to be
21+
detected by Odoo.
22+
23+
Example directory structure::
24+
25+
myupgrades/
26+
└── mymodule1/
27+
├── 18.0.1.1.2/
28+
│ └── pre-myupgrade.py
29+
└── tests/
30+
├── __init__.py
31+
└── test_myupgrade.py
32+
33+
.. note::
34+
35+
The tests in the example above will be loaded only if ``mymodule1`` is being
36+
**upgraded.**
37+
38+
Running Upgrade Tests
39+
---------------------
40+
41+
After receiving an upgraded database with all standard Odoo modules already upgraded to
42+
their target version, you can test the upgrade of custom modules by following a three-step
43+
process:
44+
45+
1. Prepare the test data
46+
47+
.. code-block:: bash
48+
49+
$ ~/odoo/$version/odoo-bin -d DB --test-tags=$prepare_test_tag \
50+
--upgrade-path=~/upgrade-util/src,~/myupgrades \
51+
--addons=~/odoo/$version/addons,~/enterprise/$version --stop
52+
53+
2. Upgrade the modules
54+
55+
.. code-block:: bash
56+
57+
$ ~/odoo/$version/odoo-bin -d DB -u mymodule1,mymodule2 \
58+
--upgrade-path=~/upgrade-util/src,~/myupgrades \
59+
--addons=~/odoo/$version/addons,~/enterprise/$version --stop
60+
61+
3. Check the upgraded data
62+
63+
.. code-block:: bash
64+
65+
$ ~/odoo/$version/odoo-bin -d DB --test-tags=$check_test_tag \
66+
--upgrade-path=~/upgrade-util/src,~/myupgrades \
67+
--addons=~/odoo/$version/addons,~/enterprise/$version --stop
68+
69+
The example above assumes that ``$version`` is the target version of your upgrade (e.g.
70+
``18.0``), ``DB`` is the name of your database, and ``mymodule1,mymodule2`` are the
71+
modules you want to upgrade. The directory structure assumes that ``~/odoo/$version`` and
72+
``~/enterprise/$version`` contain the Community and Enterprise source code for the target
73+
Odoo version, respectively. The ``~/myupgrades`` directory contains your custom upgrade
74+
scripts, and ``~/upgrade-util/src`` contains the `upgrade utils
75+
<https://github.com/odoo/upgrade-util/>`_ repo.
76+
77+
The variables ``$prepare_test_tag`` and ``$check_test_tag`` must be set according to:
78+
79+
.. list-table::
80+
:header-rows: 1
81+
:stub-columns: 1
82+
83+
* - Variable
84+
- ``UpgradeCase``
85+
- ``IntegrityCase``
86+
* - ``$prepare_test_tag``
87+
- ``upgrade.test_prepare``
88+
- ``integrity_case.test_prepare``
89+
* - ``$check_test_tag``
90+
- ``upgrade.test_check``
91+
- ``integrity_test.test_check``
92+
93+
.. note::
94+
95+
`upgrade.test_prepare` also runs ``IntegrityCase`` tests, so you can prepare data
96+
for both ``UpgradeCase`` and ``IntegrityCase`` tests with only this tag.
97+
98+
.. warning::
99+
100+
Do **not** run any ``prepare`` method before sending your database for upgrade to
101+
`upgrade.odoo.com <https://upgrade.odoo.com>`_. Doing so may cause conflicts with the
102+
tests performed during the major upgrade.
103+
104+
API documentation
105+
-----------------
106+
"""
107+
1108
import functools
2109
import inspect
3110
import logging
@@ -40,22 +147,17 @@ def parametrize(argvalues):
40147
"""
41148
Parametrize a test function.
42149
43-
Decorator for UnitTestCase test functions to parametrize the decorated test.
44-
45-
Usage:
46-
```python
47-
@parametrize([
48-
(1, 2),
49-
(2, 4),
50-
(-1, -2),
51-
(0, 0),
52-
])
53-
def test_double(self, input, expected):
54-
self.assertEqual(input * 2, expected)
55-
```
56-
57-
It works by injecting test functions in the containing class.
58-
Idea taken from the `parameterized` package (https://pypi.org/project/parameterized/).
150+
Decorator for upgrade test functions to parametrize and generate multiple tests from
151+
it.
152+
153+
Usage::
154+
155+
@parametrize([(1, 2), (2, 4), (-1, -2), (0, 0)])
156+
def test_double(self, input, expected):
157+
self.assertEqual(input * 2, expected)
158+
159+
Works by injecting test functions in the containing class.
160+
Inspired by the `parameterized <https://pypi.org/project/parameterized/>`_ package.
59161
"""
60162

61163
def make_func(func, name, args):
@@ -116,6 +218,8 @@ def __init_subclass__(cls):
116218

117219

118220
class UnitTestCase(TransactionCase, _create_meta(10, "upgrade_unit")):
221+
""":meta private: exclude from online docs."""
222+
119223
@classmethod
120224
def setUpClass(cls):
121225
super().setUpClass()
@@ -211,6 +315,8 @@ def assertUpdated(self, table, ids=None, msg=None):
211315

212316

213317
class UpgradeCommon(BaseCase):
318+
""":meta private: exclude from online docs."""
319+
214320
__initialized = False
215321

216322
change_version = (None, None)
@@ -332,6 +438,20 @@ def convert_check(self, value):
332438

333439

334440
def change_version(version_str):
441+
"""
442+
Class decorator to specify the version on which a test is relevant.
443+
444+
Using ``@change_version(version)`` indicates:
445+
446+
* ``test_prepare`` will only run if the current Odoo version is in the range
447+
``[next_major_version-1, version)``.
448+
* ``test_check`` will only run if the current Odoo version is in the range ``[version,
449+
next_major_version)``.
450+
451+
``next_major_version`` is the next major version after ``version``, e.g. for
452+
``saas~17.2`` it is ``18.0``.
453+
"""
454+
335455
def version_decorator(obj):
336456
match = VERSION_RE.match(version_str)
337457
if not match:
@@ -370,24 +490,43 @@ def get_previous_major(major, minor):
370490
# pylint: disable=inherit-non-class
371491
class UpgradeCase(UpgradeCommon, _create_meta(10, "upgrade_case")):
372492
"""
373-
Test case to modify data in origin version, and assert in target version.
493+
Test case to verify that the upgrade scripts correctly upgrade data.
374494
375-
User must define a "prepare" and a "check" method.
376-
- prepare method can write in database, return value will be stored in a dedicated table and
377-
passed as argument to check.
378-
- check method can assert that the received argument is the one expected,
379-
executing any code to retrieve equivalent information in migrated database.
380-
Note: check argument is a loaded json dump, meaning that tuple are converted to list.
381-
convert_check can be used to normalise the right part of the comparison.
495+
Override:
382496
383-
check method is only called if corresponding prepared was run in previous version
497+
* ``prepare`` to set up data,
498+
* ``check`` to assert expectations after the upgrade.
384499
385-
prepare and check implementation may contains version conditional code to match api changes.
500+
The ORM can be used in these methods to perform the functional flow under test. The
501+
return value of ``prepare`` is persisted and passed as an argument to ``check``. It
502+
must be JSON-serializable.
386503
387-
using @change_version class decorator can indicate with script version is tested here if any:
388-
Example: to test a saas~12.3 script, using @change_version('saas-12,3') will only run prepare if
389-
version in [12.0, 12.3[ and run check if version is in [12.3, 13]
504+
.. note::
390505
506+
Since ``prepare`` injects or modifies data, this type of test is intended **only
507+
for development**. Use it to test upgrade scripts while developing them. **Do not**
508+
run these tests for a production upgrade. To verify that upgrades preserved
509+
important invariants in production, use ``IntegrityCase`` tests instead.
510+
511+
.. example::
512+
513+
.. code-block:: python
514+
515+
from odoo.upgrade.testing import UpgradeCase, change_version
516+
517+
518+
@change_version("saas~18.4") # run this test only when going over saas~18.4
519+
class DeactivateBobUsers(UpgradeCase):
520+
521+
def prepare(self):
522+
u = self.env["res.users"].create({"login": "bob", "name": "Bob"})
523+
return u.id # will be passed to check
524+
525+
def check(self, uid): # uid is the value returned by prepare
526+
self.env.cr.execute(
527+
"SELECT * FROM res_users WHERE id=%s AND NOT active", [uid]
528+
)
529+
self.assertEqual(self.env.cr.rowcount, 1)
391530
"""
392531

393532
def __init_subclass__(cls, abstract=False):
@@ -403,12 +542,27 @@ def test_prepare(self):
403542
# pylint: disable=inherit-non-class
404543
class IntegrityCase(UpgradeCommon, _create_meta(20, "integrity_case")):
405544
"""
406-
Test case to check invariant through any version.
545+
Test case for validating invariants across upgrades.
546+
547+
Override:
548+
549+
* ``invariant`` to return a JSON-serializable value representing
550+
the invariant to check.
551+
552+
The ``invariant`` method is called both before and after the upgrade,
553+
and the results are compared.
554+
555+
556+
.. example::
557+
558+
.. code-block:: python
559+
560+
from odoo.upgrade.testing import IntegrityCase
407561
408-
User must define a "invariant" method.
409-
invariant return value will be compared between the two version.
410562
411-
invariant implementation may contains version conditional code to match api changes.
563+
class NoNewUsers(IntegrityCase):
564+
def invariant(self):
565+
return self.env["res.users"].search_count([])
412566
"""
413567

414568
message = "Invariant check fail"
@@ -418,7 +572,7 @@ def __init_subclass__(cls, abstract=False):
418572
if not abstract and not hasattr(cls, "invariant"):
419573
_logger.error("%s (IntegrityCase) must define an invariant method", cls.__name__)
420574

421-
# IntegrityCase should not alterate database:
575+
# IntegrityCase should not alter the database:
422576
# TODO give a test cursor, don't commit after prepare, use a protected cursor to set_value
423577

424578
def prepare(self):
@@ -438,6 +592,7 @@ def _setup_registry(self):
438592
self.addCleanup(self.registry.leave_test_mode)
439593

440594
def setUp(self):
595+
""":meta private: exclude from online docs."""
441596
super(IntegrityCase, self).setUp()
442597

443598
def commit(self):

0 commit comments

Comments
 (0)