Skip to Content

Development Guide

For module selection, setup, and user documentation, start with the repository landing page.

Tests

Test modules use test_<model_name>.py, replacing model-name dots with underscores. A descriptive suffix distinguishes scenarios for the same model. Integration files retain their existing grouping under the primary model; standalone hooks, services, and conversion utilities use their implementation name. Installation checks use test_ir_module_module_installation.py.

Use the workspace runners for Odoo integration tests on authorized disposable databases. From the repository root, a focused addon run is:

/srv/pmiverse/_pmiconfig/scripts/test/run_pytest_addon.sh \
 -a <addon/tests> -d test_<addon> -- -q --maxfail=1

The repository runner is available for an explicitly scoped full-repository run:

/srv/pmiverse/_pmiconfig/scripts/test/run_pytest_repo.sh \
 --repo /srv/pmiverse/_pmisuite18/repos/pmiverse/l10n-slovenia \
 -- --maxfail=1 -q

The runners configure pytest-odoo explicitly with plugin autoloading disabled. The root pytest.ini registers Odoo/install markers and treats deprecation warnings as errors. Addon tests/conftest.py files own their fixtures and database assumptions; l10n_pmis needs its separate base-only test setup.

Database-free policy tests are maintained outside this addon repository under /srv/pmiverse/_pmitools/pmiverse/tools/l10n_slovenia/tests/. From this repository, use the configured Python interpreter:

PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 <configured-python> -m pytest \
 -c pytest.ini -p no:cacheprovider \
 /srv/pmiverse/_pmitools/pmiverse/tools/l10n_slovenia/tests/test_l10n_pmis_policy.py

Installation, upgrades and database lifecycle operations are deployment actions. Do not point integration-test runners at an existing business database.

Documentation and Badges

Module README bodies and their localized companions are maintained directly. Keep module overviews aligned with their user manuals and with current code. The repository's test and coverage badges are maintained by the workspace badge publisher; editing documentation does not regenerate those badges.

For the localization policy's isolated prerequisites and acceptance scenarios, see its developer testing guide.