Package: z0bug-odoo
OverviewThis package is an plug-in ofzerobugpackage and aim to easily create odoo tests.It can be used replacing OCA MQT with some nice additional features.z0bug_odoois built on follow concepts:Odoo version independent; it can test Odoo from 6.1 until 17.0It is designed to run inside repository tests withlocal travis emulatorIt is designed to run in local environment too, usingzerobugIt can run with full or reduced set of pylint testsTests can use many ready-made database recordsQuality Check IdKeep database after tests (not inside travis and with some limitations)travis ci supportThe goal of z0bug_odoo is to provide helpers to ensure the quality of Odoo addons.
This package can e used replacing OCA MQT and it differs by:z0bug_odoo can also test Odoo 6.1 and 7.0 where OCA MQT fails with these versionsz0bug_odoo can also test Odoo using python2 where OCA abandoned the developing of Odoo base on python2z0bug_odoo is designed to execute some debug statements, mainly in local environmentz0bug_odoo has more options to run with reduced set of lint testsOCA MQT is the only component to build environment and test Odoo while z0bug_odoo is part ofZeroincombenze® toolsAs per prior rule, building test environment is made byvem,clodooandlisa. These commands can also build a complete Odoo environment out of the boxTo make a complete test on TravisCI your project following 3 files are required:.travis.ymlrequirements.txtoca_dependencies.txtFile .travis.ymlIn order to setup TravisCI continuous integration for your project, just copy the
content of thesample_filesto your project’s root directory.Then execute the command:make_travis_conf <TOOLS_PATH>/travis_emulator/template_travis.yml .travis.ymlYou can check travis syntax with thelint checkerof travis, if available.Notice: if you do not use travisCi web site, you can avoid to set .travis.yml file.
Local travis emulator and z0bug_odoo create local .travis.yml dinamically.Odoo test integrationCurrent Odoo project version is declared byVERSIONvariable.
If your Odoo module must be tested against Odoo core,
you can test specific github repository byODOO_REPOvariable.
You can test against:odoo/odooOCA/OCBzeroincombenze/OCBYou can test against specific Odoo core version with ODOO_BRANCH variable if differs from your project version:# Odoo Branch 16.0
- VERSION="16.0" ODOO_REPO="odoo/odoo"

# Pull request odoo/odoo#143 (not in local)
-  VERSION="pull/143" ODOO_REPO="OCA/OCB"

# Branch saas-17
- ODOO_REPO="odoo/odoo" ODOO_BRANCH="saas-17"OCB / core testZeroincombenze® OCB uses submodules. When test is starting, travis-ci upgrades repository and submodules.
To avoid submodules upgrade use this directive compatible with OCA MQT:- git:
  submodules: falsez0bg_odoo set security environment. You do not need to add any security statements.
You can avoid the following OCA MQT directive:- pip install urllib3[secure] --upgrade; truez0bg_odoo does some code upgrade.
You can avoid following directive in ODOO_TEST_SELECT=”APPLICATIONS”:- sed -i "s/self.url_open(url)/self.url_open(url, timeout=100)/g" ${TRAVIS_BUILD_DIR}/addons/website/tests/test_crawl.py;You can avoid following directive in ODOO_TEST_SELECT=”LOCALIZATION”:- sed -i "/'_auto_install_l10n'/d" ${TRAVIS_BUILD_DIR}/addons/account/__manifest__.pyPython versionOdoo version from 6.1 to 10.0 are tested with python 2.7
From Odoo 11.0, python3 is used. You can test against 3.6, 3.7, 3.8, 3.9 and 3.10 python versions.
Python 3.5 still works but support is ended.
This is the declaration:python:
  - "3.6"       # Odoo 11.0 12.0
  - "3.7"       # Odoo 12.0
  - "3.8"       # Odoo 13.0 14.0
  - "3.9"       # Odoo 15.0 16.0
  - "3.10"      # Odoo 17.0Notepython 3.5 support is ended on 2020 and 3,6 is ended on 2021.WarningCurrently, some Odoo version cannot support python 3.8+. See above.Deployment and setup environmentIn order to deploy test environment and setup code you have to declare some .travis.yml directives divides in following 3 parts:Linux packages neededPYPI packagesOdoo repositories dependenciesLinux packages must be declared in<addons/apt>section of .travis.yml using Ubuntu namespace.
If you run test in local environment, travis emulator automatically translate Ubuntu names into your local distro names, if necessary.
Seetravis emulatorguide for furthermore info.The PYPI packages, installable by PIP are declared in standard PIP way, usingrequirements.txtfile.If your project depends on other Odoo Github repositories like OCA, create a file calledoca_dependencies.txtat the root of your project and list the dependencies there.
One per line like so:project_name optional_repository_url optional_branch_nameDuring testbed setup, z0bug_odoo will automatically download and place these repositories accordingly into the addon path.
Note on addons path ordering: they will be placed after your own repo, but before the odoo core repo.If missed optional_repository_url, the repository is searched for repository with the same owner of tested project.NoteThis behaviour differs from OCA MQTOCA MQT always loads OCA repository while z0bug_odoo searches for current owner repository.
So you will test both with z0bug_odoo and both OCA MQT, always insert the full repository URL.Test executionTests run by travis_run_test command. The script is deployed in _travis directory ofzerobugpackage.
Command have to be in<script>section of .travis.yml file:script:
    - travis_run_testsIsolated pylint+flake8 checksIf you want to make a build for these checks, you can add a line
on the<env>section of the .travis.yml file with this content:- VERSION="12.0" LINT_CHECK="1"To avoid making again these checks on other builds, you have to add
LINT_CHECK=”0” variable on the line:- VERSION="12.0" ODOO_REPO="odoo/odoo" LINT_CHECK="0"You can superset above options in local travis emulator.Reduced set of lint checkYou can execute reduced set of check, in order to gradually evolve your code quality
when you meet too many errors.To enable reduced set of check add one of follow lines:- LINT_CHECK="1" LINT_CHECK_LEVEL="MINIMAL"
- LINT_CHECK="1" LINT_CHECK_LEVEL="REDUCED"
- LINT_CHECK="1" LINT_CHECK_LEVEL="AVERAGE"
- LINT_CHECK="1" LINT_CHECK_LEVEL="NEARBY"
- LINT_CHECK="1" LINT_CHECK_LEVEL="OCA"Odoo core has internal pylint test that checks for all modules even the dependecies.
So if some dependecies module does not meet this test, then the full travis test fails without testing the target repository.Please, add test_lint to EXCLUDE variable to avoid this fail-over. See below for furthermore informations.Look at follow table to understand which tests are disabled at specific level:FLAKE8 (seehttp://flake8.pycqa.org/en/latest/user/error-codes.htmlfor deatils)TestMINIMALREDUCEDAVERAGENEARBYOCANoteE117over-indentedE121continuation line under-indented for hanging indentE123Closing bracket does not match indentation of opening bracket’s lineE124Closing bracket does not match visual indentationE126Continuation line over-indented for hanging indentE127continuation line over-indented for visual indentE128Continuation line under-indented for visual indentE131continuation line unaligned for hanging indentE133Closing bracket is missing indentationE201Whitespace after ‘(’E202Whitespace before ‘)’E203Whitespace before ‘:’E211whitespace before ‘(’E221Multiple spaces before operatorE222E225E226E231E241E242E251E261E262E265E266too many leading ‘#’ for block commentE271multiple spaces after keywordE272multiple spaces before keywordW291W292no newline at end of fileW293E301Expected 1 blank lineE302No __init__.pyE303E305W391blank line at end of fileF401module imported but unusedE501E502the backslash is redundant between bracketsW503No __init__.pyW504No __init__.pyF601dictionary key name repeated with different valuesE701multiple statements on one line (colon)E722do not use bare exceptF811redefinition of unused name from line N (No __init__.py)F841local variable ‘context’ is assigned to but never usedPYLINT (seehttp://pylint-messages.wikidot.com/all-codesfor details)TestMINIMALREDUCEDAVERAGENEARBYOCANotesW0101unreachableW0312wrong-tabs-instead-of-spacesW0403relative-importW1401anomalous-backslash-in-stringE7901rst-syntax-errorC7902missing-readmeW7903javascript-lintW7908missing-newline-extrafilesW7909redundant-modulename-xmlW7910wrong-tabs-instead-of-spacesW7930file-not-usedW7935missing-import-errorW7940dangerous-view-replace-wo-priorityW7950odoo-addons-relative-importE8102invalid-commitC8103manifest-deprecated-keyW8103translation-fieldC8104class-camelcaseW8104api-one-deprecatedC8105license-allowedC8108method-computeR8110old-api7-method-definedW8202use-vim-commentN/Asql-injectionN/Aduplicate-id-csvN/Acreate-user-wo-reset-passwordN/Adangerous-view-replace-wo-priorityN/Atranslation-requiredN/Aduplicate-xml-record-idN/Ano-utf8-coding-commentN/Aattribute-deprecatedN/Aconsider-merging-classes-inheritedDisable some pylint and/or flake8 checksYou can disable some specific test or some file from lint checks.To disable flake8 checks on specific file you can add following line at the beginning of python file:# flake8: noqaTo disable pylint checks on specific file you can add following line at the beginning of python file:# pylint: skip-fileTo disable both flake8 and pylint checks on specific file you can add following line at the beginning of python file:# flake8: noqa - pylint: skip-fileTo disable pylint checks on specific XML file you can add following line in XML file after xml declaration:<!-- pylint:disable=deprecated-data-xml-node -->You can disable specific flake8 check in some source part of python file adding a comment at the same statement to disable check. Here an example to disable sql error (notice comment must be at beginning of the statement):from builtins import *  # noqa: F403If you have to disable more than one error you can add following declaration:from builtins import *  # noqaYou can also disable specific pylint check in some source part of python file adding a comment at the same statement to disable check. Here an example to disable sql error (notice comment must be at beginning of the statement):self._cr.execute()      # pylint: disable=E8103Disable unit testIf you want to make a build without tests, you can use the following directive:TEST_ENABLE="0"You will simply get the databases with packages installed,
but without running any tests.Reduced set of unit testOdoo modules may fail in Travis CI or in local environment.
Currently Odoo OCB core tests fail; we are investigating for the causes.
However you can use a simple workaround, disabling some test.
Currently tests fail are:test_impextest_ir_actionstest_linttest_main_flowstest_searchtest_user_has_groupExample:- export EXCLUDE=test_impex,test_ir_actions,test_lint,test_main_flows,test_search,test_user_has_group
- TESTS="1" ODOO_TEST_SELECT="ALL"
- TESTS="1" ODOO_TEST_SELECT="NO-CORE"
- ....You can set parameter local GBL_EXCLUDE to disable these test for all repositories.
You will be warned that local GBL_EXCLUDE has only effect for local emulation.
To avoid these test on web travis-ci you have to set EXCLUDE value in .travis.yml file.Look at follow table to understand which set of tests are enabled or disabled:statementapplicationlocal moduleodoo/addonsaddons + dependenciesALLAPPLICATIONSOnly if applicationLOCALIZATIONOnly local modulesCORENO-APPLICATIONNo if applicationNO-LOCALIZATIONNo local modulesNO-COREDependencies testSince late Summer 2021, z0bug_odoo checks for dependencies.
This test is a sub test of unit test. This is the directive:- TESTS="1" TEST_DEPENDENCIES="1"Module unit testsz0bug_odoo is also capable to test each module individually.
The intention is to check if all dependencies are correctly defined.
Activate it through theUNIT_TESTdirective.
An additional line should be added to theenv:section,
similar to this one:- VERSION="12.0" UNIT_TEST="1"Automatic module translationSince late Summer 2021, z0bug_odoo activate automatic module translation after test ended with success.
This is the directive:- VERSION="12.0" ODOO_TNLBOT="1"This feature is still experimental.Names used for the test databasesz0bug_odoo has a nice feature of organizing your testing databases.
You might want to do that if you want to double them up as
staging DBs or if you want to work with an advanced set of
templates in order to speed up your CI pipeline.
Just specify at will:MQT_TEMPLATE_DB='odoo_template'MQT_TEST_DB='odoo_test'In your local travis you can declare the default value but these values are not applied in web TravisCi web site.Database user is the current username. This behavior works both in local test both in TravisCi web site.
However, sometimes, local user and db username can be different. You can set the default value in travis emulator.Coveralls/Codecov configuration fileCoverallsandCodecovservices provide information on the test coverage of your modules.
Currently both configurations are automatic (check default configurationhere.
So, as of today, you don’t need to include a.coveragercinto the repository,
If you do it, it will be simply ignored.Other configurationsYou can highly customize you test: look at below table.variabledefault valuemeaningCHROME_TESTSet value to 1 to use chrome client to testDATA_DIR~/data_dirOdoo data directory (data_dir in config file)EXCLUDEModules to exclude from testINCLUDEModules to test (allINSTALL_OPTIONSOptions passed to odoo-bin/openerp-server to install modulesMQT_DBSUER$USERDatabase usernameMQT_TEMPLATE_DBtemplate_odooRead aboveMQT_TEST_DBtest_odooRead aboveNPM_CONFIG_PREFIX$HOME/.npm-globalN/DODOO_COMMIT_TEST0Test result will be committed; require specific code at TearDown functionODOO_REPOodoo/odooOCB repository against test repositoryODOO_SETUPS__manifest__.py __openerp__.py __odoo__.py __terp__.pyNames of Odoo manifest filesODOO_TEST_SELECTALLRead aboveODOO_TNLBOT0Read aboveOPTIONSOptions passed to odoo-bin/openerp-server to execute testsPHANTOMJS_VERSIONVersion of PhantomJSPS_TXT_COLOR0;97;40N/DPS_RUN_COLOR1;37;44N/DPS_NOP_COLOR34;107N/DPS_HDR1_COLOR97;42N/DPS_HDR2_COLOR30;43N/DPS_HDR3_COLOR30;45N/DPYPI_RUN_PYVER(2.7|3.5|3.6|3.7|3.8|3.9)python versions to run (only PYPI projects)SERVER_EXPECTED_ERRORS# of expected errors after testsTEST_DEPENDENCIES0Read aboveTRAVIS_DEBUG_MODE0Read aboveTRAVIS_PDBThe value ‘true’ activates pdb in local ‘travis -B’UNBUFFER1Use unbuffer (colors) to log resultsUNIT_TESTRead aboveTESTRead aboveVERSIONOdoo version to test (see above)WEBSITE_REPOLoad package for website testsWKHTMLTOPDF_VERSION0.12.5Version of wkhtmltopdf (value are 0.12.1Debug informationIf you declare the following directive in <env global> section:TRAVIS_DEBUG_MODE="n"where “n” means:Parameter01239Informative messagesInspect internal dataMQT testsInstallation log levelERRORWARNINFOINFOExecution log levelINFOTESTTESTTESTNote this feature does not work with OCA MQT. Local test and TravisCI test have slightly different behavior.When MQT is execute in local environment the valueTRAVIS_DEBUG_MODE="9"does not execute unit test. It is used to debug MQT itself.Seelocal travis emulatorTree directoryWhile travis is running this is the tree directory:${HOME}                         # home of virtual environment (by TravisCI)
┣━━ build                       # build root (by TravisCI)
┃    ┣━━ ${TRAVIS_BUILD_DIR}    # testing repository (by TravisCI)
┃    ┗━━ ${ODOO_REPO}           # odoo or OCB repository to check with       (0) (1) (2)
┃
┣━━ ${ODOO_REPO}-${VERSION}     # symlink of ${HOME}/build/{ODOO_REPO}       (0) (1)
┃
┣━━ dependencies                # Odoo dependencies of repository            (0) (3)
┃
┣━━ tools                       # clone of Zeroincombenze tools              (3) (4)
┃    ┃
┃    ┣━━ zerobug                # z0bug testing library
┃    ┃       ┗━━ _travis        # testing commands
┃    ┗━━ z0bug_odoo             # Odoo testing library
┃            ┗━━ travis         # testing commands
┃
┗━━ maintainer-quality-tools    # OCA testing library
     ┗━━ travis                 # testing commands

(0) Same behavior of OCA MQT
(1) Cloned odoo/odoo or OCA/OCB repository to check compatibility of testing modules
(2) If the testing project is OCB, travis_install_env ignore this directory
(3) Done by then following statements in .travis.yml:
    - travis_install_env
    Above statements replace the OCA statements:
    - travis_install_nightly
(4) Done by following statements in .travis.yml::
    - git clone https://github.com/zeroincombenze/tools.git ${HOME}/tools --depth=1
    - \${HOME}/tools/install_tools.sh -qpt
    - source ${HOME}/devel/activate_tools -t
    Above statements replace OCA following statements:
    - git clone https://github.com/OCA/maintainer-quality-tools.git ${HOME}/maintainer-quality-tools --depth=1
    - export PATH=${HOME}/maintainer-quality-tools/travis:${PATH}TestEnv: the test environmentTestEnv makes available a test environment ready to use in order to test your Odoo
module in quick and easy way.The purpose of this software are:Create the Odoo test environment with records to use for your testMake available some useful functions to test your moduleSimulate the wizard to test wizard functions (wizard simulator)Environment running different Odoo modules versionsKeep database after tests (with some limitations)Please, pay attention to test data: TestEnv use internal unicode even for python 2
based Odoo (i.e. 10.0). You should declare unicode date whenever is possible.NoteOdoo core uses unicode even on old Odoo version.For a complete set of examples, please look at the module test_testenv inrepositoryTests are based on test environment created by module mk_test_env inrepositorykeeping database after testsUsing zerobug in conjunction with z0bug_odoo a nice feature is available: you can keep
the database after tests, so you can touch teh results or build example DB.
However this feature has some limitation:You can use just 1 test class, because saving is made on TearDown executionYou cannot create on fly record with external reference of current module nameExample 1, double test class: it does not workclass TestExample(SingleTransactionCase):
    ...

class Test2Example(SingleTransactionCase):
    ...Example 2, module named “my_module”:class TestExample(SingleTransactionCase):
    ...
    # Follow record with external reference "my_module.my_xref" will be
    # automaticaaly deleted by Odoo at the end of the test
    self.resource_create("my.model", xref="my_module.my_xref", ...
    # Follow record with external reference "z0bug.my_xref" works!
    self.resource_create("my.model", xref="z0bug.my_xref", ...Names used for the test databases in testenvzerobug and z0bug_odoo use different rule from travis emulatro to naming test database.
The database name is “test_<MODULE_NAME>”.Please, notice a template database, named “template_<MODULE_NAME>” is built before test
database and then ie kept in the system.
If you do not want to see template databases use following regex for dbfilter parameter
inf your Odoo configuration file:dbfilter = (?!template).*RequirementsThs TestEnv software requires:python_plus PYPI packagez0bug_odoo PYPI package 2.0.16python 2.7 / 3.6 / 3.7 / 3.8TestEnv is full integrated with Zeroincombenze® tools.
Seereadthedocsandzeroincombenze githubZeroincombenze® tools help you to test Odoo module with pycharm.FeaturesData to use in tests are store in csv files in data directory.
File names are tha name of the models (table) with characters ‘.’ (dot) replaced by ‘_’ (underscore)Header of file must be the names of table fields.Rows can contains value to store or Odoo external reference or macro.For type char, text, html, int, float, monetary: value are constants inserted as is.For type many2one: value may be an integer (record id) or Odoo external reference (format “module.name”).For type data, datetime: value may be a constant or relative dateUsageUsage DetailsYou can locate the recent testenv.py in testenv directory of modulez0bug_odooFor full documentation visit:zero-toolsorz0bug_odooorzero-tools (github)orgithub with example modulesCopy the testenv.py file in tests directory of your module.
Please copy the documentation testenv.rst file in your module too.The __init__.py must import testenv.from . import testenv
from . import test_<MY_TEST_FILE>Your python test file have to contain some following example lines:import os
import logging
from .testenv import MainTest as SingleTransactionCase

_logger = logging.getLogger(__name__)

TEST_SETUP_LIST = ["res.partner", ]

class MyTest(SingleTransactionCase):

    def setUp(self):
        super().setUp()
        # Add following statement just for get debug information
        self.debug_level = 2
        # keep data after tests
        self.odoo_commit_data = True
        self.setup_env()                # Create test environment

    def tearDown(self):
        super().tearDown()

    def test_mytest(self):
        _logger.info(
            "🎺 Testing test_mytest"    # Use unicode char to best log reading
        )
        ...An important helper to debug is self.debug_level. When you begins your test cycle,
you are hinted to set self.debug_level = 3; then you can decrease the debug level
when you are developing stable tests.
Final code should have self.debug_level = 0.
TestEnv logs debug message with symbol “🐞 “ so you can easily recognize them.
Another useful helper is the database keep data after test feature. You have to declare
self.odoo_commit_data = True and you have to set global bash environmentglobalODOO_COMMIT_DATA="1"Ths TestEnv software requires:python_plus PYPI packagez0bug_odoo PYPI package version 2.0.16python 2.7 / 3.6 / 3.7 / 3.8 / 3.9 / 3.10Model data declarationEach model is declared in a csv file or xlsx file intest/datadirectory of the
module. The file name is the same of model name with dots replaced by undescore.i.e. below the contents ofres_parter.csvfile:id,name,street
z0bug.partner1,Alpha,"1, First Avenue"The model may also be declared in a dictionary which key which is the external
reference used to retrieve the record.i.e. the following record declaration is the same of above example; record id is namedz0bug.partner1in res.partner:TEST_RES_PARTNER = {
    "z0bug.partner1": {
        "name": "Alpha",
        "street": "1, First Avenue",
        ...
    }
)WarningPlease, do not to declareproduct.productrecords: they are automatically
created as child ofproduct.template. The external reference must contain
the pattern_template(see below).WarningWhen you write a file with a spreadsheet app, pay attention to automatic string
replacement. For example double quote char <”> may be replaced by <”>.
These replaced characters may be create some troubles during import data step,
expecially when used in “python expression”.Magic relationshipSome models/tables should be managed together, i.e.account.moveandaccount.move.line.
TestEnv manages these models/tables, called header/detail, just as a single object.
When header record is created, all detail lines are created with header.
Odoo standard declaration requires the details data in child reference field with
command0, 0.
This method make unreadable the source data. Look at the simple follow example with
usually Odoo declaration way:sale_order_data = {
    "example.order_1": {
        "partner_id": self.env.ref("base.res_partner_1"),
        "origin": "example",
        ...
        "order_line": [
            (0, 0, {
                "product_id": self.env.ref("product.product_product_1"),
                "product_qty": 1,
                "price_unit": 1.23,}),
            (0, 0, {
                "product_id": self.env.ref("product.product_product_2"),
                "product_qty": 2,
                "price_unit": 2.34,}),
        ]
    }

}Now look at the same data in internal declaration byz0bug_odoo:TEST_SALE_ORDER = {
    "example.order_1": {
        "partner_id": "base.res_partner_1",
        "origin": "example",
        ...
    }

}

TEST_SALE_ORDER_LINE = {
    "example.order_1_1": {
        "product_id": "product.product_product_1",
        "product_qty": 1,
        "price_unit": 1.23,
    },
    "example.order_1_2": {
        "product_id": "product.product_product_2",
        "product_qty": 2,
        "price_unit": 2.34,
    }
}As you can see, the data is easy readable and easy updatable. Please, notice:Sale order lines are declared in specific modelsale.order.lineRecord IDmustbegin with header ID, followed by “_” and line IDReference data do not requireself.env.ref(): they are automatically referencedIt is also easy write the csv or xlsx file. This is the example with above dataFilesale_order.csvid,partner_id,origin
example.order_1,base.res_partner_1,exampleFilesale_order_line.csvid,product_id,product_qty,price_unit
example.order_1_1,product.product_product_1,1,1.23
example.order_1_2,product.product_product_2,2,2.34In your test file you must declare the following statement:TEST_SETUP_LIST = ["sale.order", "sale.order.line"]WarningYou must declare header and lines data before create header recordNoteExternal reference coding is free: however is hinted to use the The 2
keys reference explained in “External reference” chapter.Another magic relationship is theproduct.template(product) /product.product(variant)
relationship.
Whenever aproduct.template(product) record is created,
Odoo automatically creates one variant (child) record forproduct.product.
If your test module does not need to manage product variants you can avoid to declareproduct.productdata even if this model is used in your test data.For example, you have to testsale.order.linewhich refers toproduct.product.
You simply declare aproduct.templaterecord with external reference
uses “_template” magic text.TEST_PRODUCT_TEMPLATE = {
    "z0bug.product_template_1": {
        "name": "Product alpha",
        ...
    }
)

...

TEST_SALE_ORDER_LINE = {
    "z0bug.order_1_1": {
        "product_id": "z0bug.product_product_1",
        ...
    }
)External referenceEvery record tagged by an external reference may be:Ordinary Odoo external reference(a), format “module.name”Test reference, format “z0bug.name”(b)Key value, format “external.key”(c)2 keys reference, for header/detail relationship(d)Magic reference forproduct.template/product.product(e)Ordinary Odoo external reference(a)is a record ofir.model.data;
you can see them from Odoo GUI interface.Test reference(b)are visible just in the test environment.
They are identified by “z0bug.” prefix module name.External key reference(c)is identified by “external.” prefix followed by
the key value used to retrieve the record.
If key value is an integer it is the record “id”.
The field “code” or “name” are used to search record;
for account.tax the “description” field is used.
Please set self.debug_level = 2 (or more) to log these field keys.The 2 keys reference(d)needs to address child record inside header record
at 2 level model (header/detail) relationship.
The key MUST BE the same key of the parent record,
plus “_”, plus line identifier (usuallysequencefield).
i.e.z0bug.move_1_3means: line with sequence3ofaccount.move.linewhich is child of recordz0bug.move_1ofaccount.move.
Please set self.debug_level = 2 (or more) to log these relationships.Forproduct.template(product) you must use ‘_template’ text in reference(e).
TestEnv inheritproduct.product(variant) external reference
(read above “Magic relationship”).Examples:TEST_ACCOUNT_ACCOUNT = {
    "z0bug.customer_account": {
        "code": "", ...
    }
    "z0bug.supplier_account": {
        "code": "111100", ...
    }
)

...

self.resource_edit(
    partner,
    web_changes = [
        ("country_id", "base.it"),       # Odoo external reference (type a)
        ("property_account_receivable_id",
         "z0bug.customer_account"),      # Test reference (type b)
        ("property_account_payable_id",
         "external.111100"),             # External key (type c)
    ],
)Module test execution sessionIntroductionModule test execution workflow should be:Data declaration, in file .csv or .xlszìx or in source codeBase data creation, in setUp() functionTests executionSupplemental data creation, during test execution, by group nameTest data may be managed by one or more data group; if not declared,
“base” group name is used. The “base” group will be created at the setUp()
level: it is the base test data.
Testing function may declare and manage other group data. Look at the
following example:import os
import logging
from .testenv import MainTest as SingleTransactionCase

_logger = logging.getLogger(__name__)

TEST_PRODUCT_TEMPLATE = {
    "z0bug.product_template_1": {...}
}
TEST_RES_PARTNER = {
    "z0bug.partner1": {...}
)
TEST_SETUP_LIST = ["res.partner", "product.template"]

TEST_SALE_ORDER = {
    "z0bug.order_1": {
        "partner_id": "z0bug.partner1",
        ...
    }
}
TEST_SALE_ORDER_LINE = {
    "z0bug.order_1_1": {
        "product_id": "z0bug.product_product_1",
        ...
    }
)

class MyTest(SingleTransactionCase):

    def setUp(self):
        super().setUp()
        self.debug_level = 2
        self.setup_env()                # Create base test environment

    def test_something(self):
        # Now add Sale Order data, group "order"
        self.setup_env(group="order", setup_list=["sale.order", "sale.order.line"])Note the external reference are globals and they are visible from any groups.
After base data is created, the real test session can begin. You can simulate
various situation; the most common are:Simulate web form create recordSimulate web form update recordSimulate the multi-record windows actionDownload any binary data created by testEngage wizardNoteYou can also create / update record with usually create() / write() Odoo function,
but they do not really simulate the user behavior because they do not engage the
onchange methods, they do not load any view and so on.The real best way to test a create record is like the follow example
based onres.partner model:partner = self.resource_edit(
    resource="res.partner",
    web_changes=[
        ("name", "Adam"),
        ("country_id", "base.us"),
        ...
    ],
)You can also simulate the update session, issuing the record:partner = self.resource_edit(
    resource=partner,
    web_changes=[
        ("name", "Adam Prime"),
        ...
    ],
)Look at resource_edit() documentation for furthermore details.In you test session you should need to test a wizard. This test is very easy
to execute as in the follow example that engage the standard language install
wizard:# We engage language translation wizard with "it_IT" language
# see "<ODOO_PATH>/addons/base/module/wizard/base_language_install*"
_logger.info("🎺 Testing wizard.lang_install()")
act_windows = self.wizard(
    module="base",
    action_name="action_view_base_language_install",
    default={
        "lang": "it_IT"
        "overwrite": False,
    },
    button_name="lang_install",
)
self.assertTrue(
    self.is_action(act_windows),
    "No action returned by language install"
)
# Now we test the close message
self.wizard(
    act_windows=act_windows
)
self.assertTrue(
    self.env["res.lang"].search([("code", "=", "it_IT")]),
    "No language %s loaded!" % "it_IT"
)Look at wizard() documentation for furthermore details.Data valuesData values may be raw data (string, number, dates, etc.) or external reference
or some macro.
You can declare data value on your own but you can discover the full test environment
inhttps://github.com/zeroincombenze/zerobug-test/mk_test_env/and get data
from this environment.NoteThe fieldscompany_idandcurrency_idmay be empty to use default value.
If you want to issue no value, do not declare column in model file (csv or xlsx).You can evaluate the field value engaging a simple python expression inside tags like in
following syntax:“<?odoo EXPRESSION ?>”The expression may be a simple python expression with following functions:functiondescriptionexamplecompute_dateCompute date<?odoo compute_date(‘<###-##-##’)[0:4] ?>randomGenerate random number from 0.0 to 1.0<?odoo int(random() * 1000) ?>refOdoo reference self.env.ref()<?odoo ref(‘product.product_product_1’) ?>ref[field]field of record of external reference<?odoo ref(‘product.product_product_1’).name ?>ref[field]field of record of external reference (brief)<?odoo product.product_product_1.name ?>company_idIf value is empty, user company is used.
This behavior is not applied onres.users,res.partner,product.templateandproduct.productmodels.
For these models you must fill thecompany_idfield.When data is searched byresource_search()function on every model with company_id,
thecompany_idfield is automatically added to search domain, using ‘or’ between
company_id null and company_id equal to supplied value or current user company.booleanYou can declare boolean value:by python boolean False or Trueby integer 0 or 1by string “0” or “False” or “1” or “True”self.resource_create(
    "res.partner",
    xref="z0bug.partner1",
    values={
         {
            ...
            "supplier": False,
            "customer": "True",
            "is_company": 1,
        }
    }
)char / textChar and Text values are python string; please use unicode whenever is possible
even when you test Odoo 10.0 or less.self.resource_create(
    "res.partner",
    xref="z0bug.partner1",
    values={
         {
            "name": "Alpha",
            "street": "1, First Avenue"
            # Name of Caserta city
            "city": "<? base.state_it_ce.name ?>",
            # Reference: 'year/123'
            "ref": "<? compute_date('####-##-##')[0:4] + '/123' ?>",
        }
    }
)integer / float / monetaryInteger, Floating and Monetary values are python integer or float.
If numeric value is issued as string, it is internally converted
as integer/float.self.resource_create(
    "res.partner",
    xref="z0bug.partner1",
    values={
         {
            ...
            "color": 1,
            "credit_limit": 500.0,
            "payment_token_count": "0",
        }
    }
)date / datetimeDate and Datetime value are managed in special way.
They are processed bycompute_date()function (read below).
You can issue a single value or a 2 values list, 1st is the date,
2nd is the reference date.self.resource_create(
    "res.partner",
    xref="z0bug.partner1",
    values={
         {
            ...
            "activity_date_deadline": "####-1>-##",    # Next month
            "signup_expiration": "###>-##-##",         # Next year
            "date": -1,                                # Yesterday
            "last_time_entries_checked":
                [+2, another_date],                    # 2 days after another day
            "message_last_post": "2023-06-26",         # Specific date, ISO format
        }
    }
)many2oneYou can issue an integer (if you know exactly the ID)
or an external reference. Read above about external reference.self.resource_create(
    "res.partner",
    xref="z0bug.partner1",
    values={
         {
            ...
            "country_id": "base.it",                   # Odoo external reference
            "property_account_payable_id":
                "z0bug.customer_account",              # Test record
            "title": "external.Mister"                 # Record with name=="Mister"
        }
    }
)one2many / many2manyThe one2many and many2many field may contains one or more ID;
every ID use the same above many2one notation with external reference.
Value may be a string (just 1 value) or a list.self.resource_create(
    "res.partner",
    xref="z0bug.partner1",
    values={
         {
            ...
            "bank_ids":
                [
                    "base.bank_partner_demo",
                    "base_iban.bank_iban_china_export",
                ],
            "category_id": "base.res_partner_category_0",
        }
    }
)NoteYou can also use tha classic Odoo syntax with commands:
You can integrate classic Odoo syntax withz0bug_odoo externalreference.[0, 0, values (dict)]               # CREATE record and link[1, ID (int), values (dict)]        # UPDATE linked record[2, ID (int)]                       # DELETE linked record by ID[3, ID (int)]                       # UNLINK record ID (do not delete record)[4, ID (int)]                       # LINK record by ID[5, x] or [5]                       # CLEAR unlink all record IDs[6, x, IDs (list)]                  # SET link record IDsbinaryBinary file are supplied with os file name. Test environment load file and
get binary value. File must be located intests/datadirectory.self.resource_create(
    "res.partner",
    xref="z0bug.partner1",
    values={
         {
            ...
            "image": "z0bug.partner1.png"
        }
    }
)Useful External Referenceidnamemodelnotez0bug.coa_bankBankaccount.accountDefault bank accountexternal.INVSale journalaccount.journalDefault sale journalexternal.BILLPurchase journalaccount.journalDefault purchase journalexternal.MISCMiscellaneous journalaccount.journalDefault miscellaneous journalexternal.BNK1Bank journalaccount.journalDefault bank journalaccount.account_payment_term_immediateImmediate Paymentaccount.payment.termaccount.account_payment_term_net30 Net Daysaccount.payment.termz0bug.tax_22aPurchase 22% VATaccount.taxItalian default purchase VAT ratez0bug.tax_22vSale 22% VATaccount.taxItalian default sale VAT ratebase.main_companyDefault companyres.companyDefault company for testproduct.product_category_1All / Saleableproduct.categoryUseful product categorybase.USDUSD currencyres.currencyTest currency during test execution: US dollarbase.user_rootAdministratorres.usersUser under test executionFunctionscast_typescast_types(self, resource, values, fmt=None, group=None, not_null=False)Convert resource fields in appropriate type, based on Odoo type.Args:resource (str): Odoo model namevalues (dict): record datafmt (selection): output formatgroup (str): used to manager group data; default is “base”Returns:Appropriate valuesThe parameter fmt declares the purpose of casting and declare the returned format of
<2many> fields as follows table:| fmt=='cmd'         | fmt=='id'  | fmt=='py'
<2many> [(0|1,x,dict)]          | [(0|1,x,dict)] *   | [dict] *   | [dict] *
<2many> [(0|1,x,xref)]          | [(0|1,x,dict)]     | [dict]     | [dict]
<2many> [(2|3|4|5,id)]          | as is              | as is      | as is
<2many> [(2|3|4|5,xref)]        | [(2|3|4|5,id)]     | as is      | as is
<2many> [(6,0,[ids])]           | as is              | [ids]      | [ids]
<2many> [(6,0,xref)]            | [(6,0,[id])]       | [id]       | [id]
<2many> [(6,0,[xref,...])]      | [(6,0,[ids])]      | [ids]      | [ids]
<2many> dict                    | [(0,0,dict)        | [dict]     | [dict]
<2many> xref (exists)           | [(6,0,[id])]       | [id]       | [id]
<2many> xref (not exists)       | [(0,0,dict)]       | [dict]     | [dict]
<2many> [xref] (exists)         | [(6,0,[id])]       | [id]       | [id]
<2many> [xref] (not exists)     | [(0,0,dict)]       | [dict]     | [dict]
<2many> [xref,...] (exists)     | [(6,0,[ids])]      | [ids]      | [ids]
<2many> [xref,...] (not exists) | [(0,0,dict),(...)] | [dict,...] | [dict,...]
<2many> [ids] **                | [(6,0,[ids])]      | [ids]      | [ids]
<2many> id                      | [(6,0,[id])]       | [id]       | [id]
<2many> "xref,..." (exists)     | [(6,0,[ids])]      | [ids]      | [ids]
<2many> "xref,..." (not exists) | [(0,0,dict),(...)] | [dict,...] | [dict,...]

Caption: dict -> {'a': 'A', ..}, xref -> "abc.def", id -> 10, ids -> 1,2,...
* fields of dict are recursively processed
** ids 1-6 have processed as Odoo cmdfmt ==  ‘cmd’ means convert to Odoo API format: <2many> fields are returned with
prefixed 0|1|2|3|4|5|6 value (read _cast_2many docs).fmt == ‘id’ is like ‘cmd’: prefix are added inside dict not at the beginning.fmt == ‘py’ means convert to native python (remove all Odoo command prefixes).
It is used for comparison.When no format is required (fmt is None), some conversion may be not applicable:<many2one> field will be left unchanged when invalid xref is issued and <2many>
field me will be left unchanged when one or more invalid xref are issued.str, int, long, selection, binary, html fields are always left as isdate, datetime fields and fmt==’cmd’ and python2 (odoo <= 10.0) return ISO format
many2one fields, if value is (int|long) are left as is; if value is (xref) the
id of xref is returned.NoteOdoo one2many valid cmd are: 0,1 and 2 (not checked)store_resource_datastore_resource_data(self, resource, xref, values, group=None, name=None)Store a record data definition for furthermore use.Args:resource (str): Odoo model namexref (str): external referencevalues (dict): record datagroup (str): used to manager group data; default is “base”name (str): label of dataset; default is resource nameData stored is used bysetup_env()function and/or by:resource_create()without valuesresource_write()without valuesresource_make()without valuescompute_datecompute_date(self, date, refdate=None)Compute date or datetime against today or a reference date.Args:date (date or string or integer): text date formularefdate (date or string): reference dateDate may be:python date/datetime valuestring with ISO format “YYYY-MM-DD” or “YYYY-MM-DD HH:MM:SS”string value that is a relative date against today or reference dateRelative string format is like ISO, with 3 groups separated by ‘-’ (dash).
Every group may be an integer or a special notation:starting with ‘<’ meas subtract; i.e. ‘<2’ means minus 2ending with ‘>’ meas add; i.e. ‘2>’ means plus 2‘#’ with ‘<’ or ‘>’ means 1; i.e. ‘<###’ means minus 1all ‘#’ means same value of reference dateA special notation ‘+N’ and ‘-N’, where N is an integer means add N days
or subtract N day from reference date.
Here, in following examples, are used python iso date convention:‘+N’: return date + N days to refdate (python timedelta)‘-N’: return date - N days from refdate (python timedelta)‘%Y-%m-%d’: strftime of issued value‘%Y-%m-%dT%H:%M:%S’: same datetime‘%Y-%m-%d %H:%M:%S’: same datetime‘####-%m-%d’: year from refdate (or today), month ‘%m’, day ‘%d’‘####-##-%d’: year and month from refdate (or today), day ‘%d’‘2024-##-##’: year 2024, month and day from refdate (or today)‘<###-%m-%d’: year -1  from refdate (or today), month ‘%m’, day ‘%d’‘<001-%m-%d’: year -1  from refdate (or today), month ‘%m’, day ‘%d’‘<###-#>-%d’: year -1  from refdate, month +1 from refdate, day ‘%d’‘<005-2>-##’: year -5, month +2 and day from refdateNotes:Returns a ISO format string.Returned date is a valid date; i.e. ‘####-#>-31’, with ref month January result ‘####-02-31’ becomes ‘####-03-03’To force last day of month, set ‘99’: i.e. ‘####-<#-99’ becomes the last day of previous month of refdateresource_browseresource_browse(self, xref, raise_if_not_found=True, resource=None, group=None)Bind record by xref, searching it or browsing it.
This function returns a record using issued parameters. It works in follow ways:With valid xref it work exactly like self.env.ref()If xref is an integer it works exactly like self.browse()I xref is invalid, xref is used to search recordxref is searched in stored dataxref (“MODULE.NAME”): if MODULE == “external”, NAME is the record keyArgs:xref (str): external referenceraise_if_not_found (bool): raise exception if xref not found orif more records foundresource (str): Odoo model name, i.e. “res.partner”group (str): used to manager group data; default is “base”Returns:obj: the Odoo model recordRaises:ValueError: if invalid parameters issuedresource_createCreate a test record and set external ID to next tests.
This function works as standard Odoo create() with follow improvements:It can create external reference tooIt can use stored data if no values suppliedUse new api even on Odoo 7.0 or lessArgs:resource (str): Odoo model name, i.e. “res.partner”values (dict): record data (default stored data)xref (str): external reference to creategroup (str): used to manager group data; default is “base”Returns:obj: the Odoo model record, if createdresource_writeUpdate a test record.
This function works as standard Odoo write() with follow improvements:If resource is a record, xref is ignored (it should be None)It resource is a string, xref must be a valid xref or an integerIf values is not supplied, record is restored to stored data valuesdef resource_write(self, resource, xref=None, values=None, raise_if_not_found=True, group=None):Args:resource (str|obj): Odoo model name or record to update
xref (str): external reference to update: required id resource is string
values (dict): record data (default stored data)
raise_if_not_found (bool): raise exception if xref not found or if more records found
group (str): used to manager group data; default is “base”Returns:obj: the Odoo model recordRaises:ValueError: if invalid parameters issuedresource_makeCreate or write a test record.
This function is a hook to resource_write() or resource_create().def resource_make(self, resource, xref, values=None, group=None):declare_resource_dataDeclare data to load on setup_env().Args:resource (str): Odoo model name, i.e. “res.partner”data (dict): record dataname (str): label of dataset; default is resource namegroup (str): used to manager group data; default is “base”merge (str): values are (“local”|”zerobug”)Raises:TypeError: if invalid parameters issueddeclare_all_dataDeclare all data to load on setup_env()Args:message (dict): data messageTEST_SETUP_LIST (list): resource list to loadTEST_* (dict): resource data; * is the uppercase resource name wheredot are replaced by “_”; (see declare_resource_data)group (str): used to manager group data; default is “base”merge (str): values are (“local”|”zerobug”)data_dir (str): data directory, default is “tests/data”Raises:TypeError: if invalid parameters issuedget_resource_dataGet declared resource data; may be used to test compareArgs:resource (str): Odoo model name or name assigned, i.e. “res.partner”xref (str): external referencegroup (str): if supplied select specific group data; default is “base”try_again (bool): engage conveyed valueReturns:dictionary with data or empty dictionaryget_resource_data_listGet declared resource data list.def get_resource_data_list(self, resource, group=None):Args:resource (str): Odoo model name or name assigned, i.e. “res.partner”
group (str): if supplied select specific group data; default is “base”Returns:list of dataget_resource_listGet declared resource list.def get_resource_list(self, group=None):Args:group (str): if supplied select specific group data; default is “base”setup_companySetup company values for current user.This function assigns company to current user and / or can create xref aliases
and /or can update company values.
This function is useful in multi companies tests where different company values
will be used in different tests. May be used in more simple test where company
data will be updated in different tests.
You can assign partner_xref to company base by group; then all tests executed
after setup_env(), use the assigned partner data for company of the group.
You can also create more companies and assign one of them to test by group.Args:company (obj): company to update; if not supplied a new company is createdxref (str): external reference or alias for main companypartner_xref (str): external reference or alias for main company partnerrecv_xref (str): external reference or alias for receivable accountpay_xref (str): external reference or alias for payable accountbnk1_xref (str): external reference or alias for 1st liquidity bankvalues (dict): company data to update immediatelygroup (str): if supplied select specific group data; default is “base”Returns:default company for usersetup_envCreate all record from declared data.This function starts the test workflow creating the test environment.
Test data must be declared before engage this function by file .csv or
file .xlsx or by source declaration TEST_<MODEL>.setup_env may be called more times with different group value.
If it is called with the same group, it recreates the test environment with
declared values; however this feature might do not work for some reason: i.e.
if test creates a paid invoice, the setup_env() cannot unlink invoice.
If you want to recreate the same test environment, assure the conditions for
unlink of all created and tested records.If you create more test environment with different group you can grow the data
during test execution with complex scenario.
In this way you can create functional tests not only regression tests.Args:lang (str): install & load specific languagelocale (str): install locale module with CoA; i.e l10n_itgroup (str): if supplied select specific group data; default is “base”source (str): values are (“local”|”zerobug”)setup_list (list): list of Odoo modelS; if missed use TEST_SETUP_LISTdata_dir (str): data directory, default is “tests/data”Returns:Noneresource_editServer-side web form editing.Ordinary Odoo test use the primitive create() and write() function to manage
test data. These methods create an update records, but they do not properly
reflect the behaviour of user editing form with GUI interface.This function simulates the client-side form editing in the server-side.
It works in the follow way:It can simulate the form create recordIt can simulate the form update recordIt can simulate the user data inputIt calls the onchange functions automaticallyIt may be used to call button in the formUser action simulation:The parameter <web_changes> is a list of user actions to execute sequentially.
Every element of the list is another list with 2 or 3 values:Field name to assign valueValue to assignOptional function to execute (i.e. specific onchange)If field is associated to an onchange function the relative onchange functions
are execute after value assignment. If onchange set another field with another
onchange the relative another onchange are executed until all onchange are
exhausted. This behavior is the same of the form editing.Warning: because function are always executed at the server side the behavior
may be slightly different from actual form editing. Please take note of
following limitations:update form cannot simulate discard buttonsome required data in create must be supplied by default parameterform inconsistency cannot be detected by this functionnested function must be managed by test code (i.e. wizard from form)See test_testenv module for test exampleshttps://github.com/zeroincombenze/zerobug-test/tree/12.0/test_testenvdef resource_edit(self, resource, default={}, web_changes=[], actions=[], ctx={}):Args:resource (str or obj): if field is a string simulate create web behavior of
Odoo model issued in resource;
if field is an obj simulate write web behavior on the issued record
default (dict): default value to assign
web_changes (list): list of tuples (field, value); see <wiz_edit>Returns:windows action to execute or obj recordwizardExecute a full wizard.Engage the specific wizard, simulate user actions and return the wizard result,
usually a windows action.It is useful to test:view nameswizard structurewizard codeBoth parameters <module> and <action_name> must be issued in order to
call <wiz_by_action_name>; they are alternative to act_windows.* Example of use *XML view file:
    <record id="action_example" model="ir.actions.act_window">
        <field name="name">Example</field>
        <field name="res_model">wizard.example</field>
        [...]
    </record>Python code:act_windows = self.wizard(module="module_example",
    action_name="action_example", ...)
if self.is_action(act_windows):
    act_windows = self.wizard(act_windows=act_windows, ...)User action simulation:The parameter <web_changes> is a list of user actions to execute sequentially.
Every element of the list is another list with 2 or 3 values:Field name to assign valueValue to assignOptional function to execute (i.e. specific onchange)If field is associated to an onchange function the relative onchange functions
are execute after value assignment. If onchange set another field with another
onchange the relative another onchange are executed until all onchange are
exhausted. This behavior is the same of the form editing.def wizard(self, module=None, action_name=None, act_windows=None, records=None, default=None, ctx={}, button_name=None, web_changes=[], button_ctx={},):Args:module (str): module name for wizard to test; if “.” use current module name
action_name (str): action name
act_windows (dict): Odoo windows action (do not issue module & action_name)
records (obj): objects required by the download wizard
default (dict): default value to assign
ctx (dict): context to pass to wizard during execution
button_name (str): function name to execute at the end of then wizard
web_changes (list): list of tuples (field, value); see above
button_ctx (dict): context to pass to button_name functionReturns:result of the wizardRaises:ValueError: if invalid parameters issuedvalidate_recordValidate records against template values.
During the test will be necessary to check result record values.
This function aim to validate all the important values with one step.
You have to issue 2 params: template with expected values and record to check.
You can declare just some field value in template which are important for you.
Both template and record are lists, record may be a record set too.
This function do following steps:matches templates and record, based on template supplied datacheck if all template are matched with 1 record to validateexecute self.assertEqual() for every field in templatecheck for every template record has matched with assertdef validate_records(self, template, records):Args:template (list of dict): list of dictionaries with expected values
records (list or set): records to validate valuesReturns:list of matched coupled (template, record) + # of assertionsRaises:ValueError: if no enough assertions or one assertion is failedget_records_from_act_windowsGet records from a windows message.def get_records_from_act_windows(self, act_windows):Args:act_windows (dict): Odoo windows action returned by a wizardReturns:records or FalseRaises:ValueError: if invalid parameters issuedGetting startedPrerequisitesZeroincombenze tools requires:Linux Centos 7/8 or Debian 9/10 or Ubuntu 18/20/22python 2.7+, some tools require python 3.6+, best python 3.8+bash 5.0+InstallationFor stable version:pip install z0bug_odooFor current version:cd $HOMEgit@github.com:zeroincombenze/tools.gitcd $HOME/tools./install_tools.shUpgradeStable version via Python Packagepip install --upgrade z0bug_odooCurrent version via Gitcd ./tools
./install_tools.sh -pUT
source $HOME/devel/activate_toolsChangeLog History2.0.16 (2024-02-17)[FIX] TestEnv: nested +multi fields with Odoo cmd2.0.15 (2024-01-27)[IMP] Documentation typo corrections[IMP] Date range file .xlsx for TestEnv[IMP] TestEnv: local data dir new rules[FIX] TestEnv: 3 level xref, sometime fails with “_” in module name[FIX] TestEnv: caller environment more than 1 level[FIX] TestEnv: sometime is_action() fails[FIX] TestEnv: wizard active model[FIX] TestEnv: wizard module name is current module under test[IMP] TestEnv: binding model in view for Odoo 11.0+[IMP] TestEnv: write with xref can update xref id[IMP] TestEnv: warning if no setUp() declaration[IMP] TestEnv: resource_download, now default filed name is “data”2.0.14 (2023-12-22)[IMP] TestEnv: commit odoo data became internal feature[IMP] TestEnv: test on model asset.asset[IMP] TestEnv: detail external reference coding free[IMP] TestEnv: empty currency_id is set with company currency[FIX] TestEnv: minor fixes in mixed environment excel + zerobug[FIX] TestEnv: sometimes external.KEY did not work[FIX] TestEnv: 3 level xref fails when module ha “_” in its name[IMP] _check4deps.py: documentation clearing2.0.13 (2023-12-01)[IMP] TestEnv: now you can declare you own source data directory[IMP] TestEnv: file account.account.xlsx with l10n_generic_oca + some useful records[IMP] TestEnv: file account.tax.xlsx with some italian taxes for l10n_generic_oca[IMP] TestEnv: simple expression for data value2.0.12 (2023-09-12)[FIX] TestEnv: validate_records with 2 identical template records2.0.10 (2023-07-02)[IMP] TestEnv: new feature, external reference with specific field value[REF] TestEnv: tomany casting refactoring2.0.9 (2023-06-24)[FIX] TestEnv: sometimes, validate_records does not match many2one fields[FIX[ TestEnv: sometime crash in wizard on Odoo 11.0+ due inexistent ir.default[FIX] TestEnv: default value in wizard creation, overlap default function[FIX] TestEnv: record not found for xref of other group[IMP] TestEnv: resource_bind is not more available: it is replaced by resource_browse2.0.8 (2023-04-26)[FIX] TestEnv: multiple action on the same records2.0.7 (2023-04-08)[NEW] TestEnv: assertion counter[IMP] TestEnv: is_xref recognizes dot name, i.e “zobug.external.10”[IMP] TestEnv: the field <description> is not mode key (only acount.tax)[IMP] TestEnv: 3th level xref may be a many2one field type2.0.6 (2023-02-20)[FIX] TestEnv: _get_xref_id recognize any group[FIX] TestEnv: datetime field more precise (always with time)[FIX] TestEnv: resource_make / resource_write fall in crash if repeated on headr/detail models[NEW] TestEnv: 2many fields accepts more xref values[IMP] TestEnv: debug message with more icons and more readable[IMP] TestEnv: cast_types with formatting for python objects[IMP] TestEnv: validate_record now uses intelligent algorithm to match pattern templates and records2.0.5 (2023-01-25)[FIX] TestEnv: in some rare cases, wizard crashes[NEW] TestEnv: get_records_from_act_windows()[IMP] TestEnv: resource_make now capture demo record if available[IMP] TestEnv: resource is not required for declared xref[IMP] TestEnv: self.module has all information about current testing module[IMP] TestEnv: conveyance functions for all fields (currenly jsust for account.payment.line)[IMP] TestEnv: fields many2one accept object as value[IMP] TestEnv: function validate_records() improvements[FIX] TestEnv: company_setup, now you can declare bank account[IMP] TesEnv: minor improvements2.0.4 (2023-01-13)[FIX] TestEnv: resource_create does not duplicate record[FIX] TestEnv: resource_write after save calls write() exactly like Odoo behavior[NEW] TestEnv: new function field_download()[NEW] TestEnv: new function validate_records()[IMP] TestEnv: convert_to_write convert binary fields too[IMP] TestEnv: minor improvements2.0.3 (2022-12-29)[IMP] TestEnv: more debug messages[IMP] TestEnv: more improvements[FIX] TestEnv: sometime crashes if default use context[FIX] TestEnv: bug fixes2.0.2 (2022-12-09)[FIX] Automatic conversion of integer into string for ‘char’ fields[IMP] TestEnv2.0.1.1 (2022-11-03)[REF] clone_oca_dependencies.py2.0.1 (2022-10-20)[IMP] Stable version2.0.0.1 (2022-10-15)[FIX] Crash in travis2.0.0 (2022-08-10)[REF] Stable versionCreditsCopyrightSHS-AV s.r.l. <https://www.shs-av.com/>AuthorsSHS-AV s.r.l.ContributorsAntonio M.VigliottiAntonio Maria Vigliotti