Существует множество способов протестировать приложение. В Odoo у мы используем три вида тестов
- python unit tests: useful for testing model business logic
- js unit tests: this is necessary to test the javascript code in isolation
- tours: this is a form of integration testing. The tours ensure that the python and the javascript parts properly talk to each other.
Тестирование кода Python
Odoo обеспечивает поддержку тестирования модулей с использованием unittest.
Чтобы написать тесты, просто определите субмодуль``tests`` в вашем модуле, он будет автоматически запущен для тестирования модулей. Модули тестирования должны иметь имя, начинающееся с test_, и должны быть импортированы из tests/__init__.py, например:
your_module
|-- ...
`-- tests
|-- __init__.py
|-- test_bar.py
`-- test_foo.py
а __init__.py содержит:
from . import test_foo, test_bar
Предупреждение
Модули тестирования, которые импортируются не из tests/__init__.py запускаться не будут
Изменено в версии 8.0: previously, the test runner would only run modules added to two lists
fast_suite and checks in tests/__init__.py. In 8.0 it will
run all imported modules
При тестировании будет запускаться любой тест, как описано в официальной unittest documentation, но Odoo предоставляет ряд утилит и помощников, связанных с тестированием контента Odoo (главным образом модулей):
class odoo.tests.common.TransactionCase(methodName='runTest')[исходный код]
TestCase, в котором каждый тестовый метод запускается в своей транзакции и с собственным курсором. Откат транзакции и закрытие курсора после каждого теста.
browse_ref(xid)[исходный код]
Возвращает объект записи для предоставленного external identifier
module.identifierBaseModelref(xid)[исходный код]
Возвращает ID базы данных для предоставленного external identifier, ярлык для get_object_reference
module.identifierclass odoo.tests.common.SingleTransactionCase(methodName='runTest')[исходный код]
TestCase, в которой все тестовые методы запускаются в одной транзакции, транзакция запускается с помощью первого метода тестирования и откатывается в конце последнего.
browse_ref(xid)[исходный код]
Возвращает объект записи для предоставленного external identifier
module.identifierBaseModelref(xid)[исходный код]
Возвращает ID базы данных для предоставленного external identifier, ярлык для get_object_reference
module.identifierclass odoo.tests.common.SavepointCase(methodName='runTest')[исходный код]
Аналогичен SingleTransactionCase в том, что все методы тестирования выполняются в одной транзакции, но каждый TestCase выполняется в откатанной точке сохранения (под-транзакции).
Полезно для тестовых случаев, содержащих быстрые тесты, но со значительной настройкой базы данных, общей для всех случаев (сложные тестовые данные в бд): :meth:[UNKNOWN NODE problematic]~.setUpClass`может использоваться для генерации тестовых данных БД один раз и тогда все TestCase будут использовать одни и те же данные, не влияя друг на друга, и без необходимости заново создавать тестовые данные.
class odoo.tests.common.HttpCase(methodName='runTest')[исходный код]
Transactional HTTP TestCase with url_open and phantomjs helpers.
browse_ref(xid)[исходный код]
Возвращает объект записи для предоставленного external identifier
module.identifierBaseModelphantom_js(url_path, code, ready='window', login=None, timeout=60, **kw)[исходный код]
Протируетjs код запустив его в браузере - дополнительно авторизуется в системе как login, загрузит объявленную страницу url_path, дождется пока объект сможет быть выполнен и исполнит code внутри страницы
To signal success test do: console.log(„ok“)
To signal failure do: console.log(„error“)
If neither are done before timeout test fails.
ref(xid)[исходный код]
Возвращает ID базы данных для предоставленного external identifier, ярлык для get_object_reference
module.identifierПо умолчанию тесты запускаются сразу после установки соответствующего модуля. Но можно настроить, чтобы тестирование запускалось после установки всех модулей, а не после установки одного модуля:
odoo.tests.common.at_install(flag)[исходный код]
Устанавливает состояние at-install для теста, флаг является логическим значением, указывающим, должен ли тест (True) или не должен (False) выполняться во время установки модуля.
По умолчанию тесты запускаются сразу после установки модуля перед началом установки следующего модуля.
odoo.tests.common.post_install(flag)[исходный код]
Устанавливает состояние после установки теста. Флаг является логическим параметром, определяющим, должен ли тест запускаться или не запускаться после установки набора модулей.
По умолчанию тесты не запускаются после установки всех модулей в текущем наборе для.
Наиболее распространенная ситуация заключается в использовании TransactionCase и тестирования свойства модели в каждом методе:
class TestModelA(common.TransactionCase):
def test_some_action(self):
record = self.env['model.a'].create({'field': 'value'})
record.some_action()
self.assertEqual(
record.field,
expected_field_value)
# other tests...
Примечание
Методы тестов должны начинаться с test_
Выполнение тестов
Тесты автоматически запускаются при установке или обновлении модулей, если опция --test-enable была включена при запуске сервера Odoo.
As of Odoo 8, running tests outside of the install/update cycle is not supported.
Тестирование JS кода
Инструмент для тестирования Qunit
Odoo Web includes means to unit-test both the core code of Odoo Web and your own javascript modules. On the javascript side, unit-testing is based on QUnit with a number of helpers and extensions for better integration with Odoo.
To see what the runner looks like, find (or start) an Odoo server
with the web client enabled, and navigate to /web/tests
This will show the runner selector, which lists all modules with javascript
unit tests, and allows starting any of them (or all javascript tests in all
modules at once).
Clicking any runner button will launch the corresponding tests in the bundled QUnit runner:
Writing a test case
This section will be updated as soon as possible.
Интеграционное тестирование
Тестирование кода Python и кода JS по отдельности очень полезно, но это не доказывает, что веб-клиент и сервер работают вместе. Чтобы сделать это, мы можем написать другой вид теста: туры. Тур - это мини-сценарий описывающи бизнес-процесс. Он объясняет последовательность шагов, которые должны быть выполнены. Затем организатор теста создаст браузер phantom_js, укажет ему правильный URL-адрес и смоделирует клики и ввод данных в соответствии со сценарием.