ZestyBeanz Technologies Pvt Ltd 4th Floor, Nila, Technopark Thiruvananthapuram,
India – 695581
Phone: +91 471 4063254
Fax : +91 471 2700171


ZestyBeanz Technologies Pvt Ltd
2987, Manikkath Cross Road
Ravipuram, Kochi, India - 682016
Phone: +91 484 4063254


Zesty Labs
Office # 2003, Millennium Plaza Building
Sheikh Zayed Rd, Dubai, UAE
Phone: +971 4333 2222​
Mobile: +971-56-2708993​


ZestyBeanz Technologies GmbH
Reuterstraße 1
90408 Nürnberg
Fon: +49 911 4801 444
Fax: +49 911 4801 445

Odoo Addons Quality Check

Contact Form

S T Mohammed's picture

Odoo Addons Quality Check

Quality of your odoo addons is important to meets the desirable goals of your project. Good quality code is happens as a result of consistent and passionate focus by the developer to meet the goals. Quality measures include following certain rules to write clean code and also giving desired dependencies.

Messy code is hard to read, and people may lose interest if they cannot understand outcome of code. On the other hand a  clean code is easy to understand and helpful for later bug fixing or adding new functionality.

Focusing on Code Quality ensures lines of code written by developers follow a good coding standard or style guide.

Odoo Community Association (OCA) has a Maintainer Quality Tools(MQT) project that helps to ensure the quality of Odoo addons. This Project use Travis CI continuous integration service and Coveralls code coverage reporting service. Both services are free for open source projects and paid for private projects, so to use these services for free. To use this service, we need to have a GitHub repository with our modules. We can easily integrate the OCA maintainer-quality-tools with your repository

For this first you have go to travis page then sign in using your github  repository, then you have to sync your repository with travis.

If your project depends on other OCA or other Github repositories, create a file called 'oca_dependencies.txt' at the root of your project and list the dependencies there. One per line like so:

project_name optional_repository_url optional_branch_name

During testbed setup, MQT 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.

Isolated pylint+flake8 checks

If you want to make a build exclusive for these checks, you can add a line on the `env:` section of the .travis.yml file with this content:


To avoid making again these checks on other builds, you have to add LINT_CHECK="0" variable on the line:

- VERSION="9.0" ODOO_REPO="odoo/odoo" LINT_CHECK="0"

Disable test

If you want to make a build without tests, you can use the following directive:


You will simply get the databases with packages installed, but without running any tests. You can configure travis for your project with travis.yml file

Sample travis.yml file is here :

You have to add the .travis.yml to the top level of an Odoo addon GitHub repository that needs to run tests. Then go to your page and click on your project's name. You should see a first build in progress. If your code follows the OCA coding standard it shows green.

When you enable Travis CI on a repository, Travis registers a hook on GitHub. By default, the hook will trigger a Travis CI build for each push to a branch of the repository and for each pull request. Pull requests are built on a temporary merge of the PR, to ensure that the merged branches pass the tests.

Important Terms in travis.yml :-

add ons: This has nothing to do with Odoo addon modules. It's used to ask Travis to install some Ubuntu packages using distribution packages in the testing environment.This saves us from installing Python packages such as python-lxml from source,which takes a lot of time.

env: This section defines environment variables and the build matrix. The maintainer quality tools use these environment variables to know what to test, and will run each env line in a separate test run:

VERSION: This is the Odoo version to test against.

LINT_CHECK: Use 0 for a build with no flake8 or Pylint tests, and 1 otherwise. In the matrix, we set the first build to perform the lint check, as this is fast and we want rapid feedback if the coding standards are not met or if the linter finds errors.

TESTS: Use 0 for a build in which the module tests are not run; otherwise use 1.

ODOO_REPO: This is the GitHub repository for Odoo to test against when TESTS is 1. In the recipe, we set up a build against both the official repository and the community backports repository If unset, only the official repository is used.

Install: This sections downloads maintainer-quality-tools in the build environment and calls the travis_install_nightly utility, which will set up Odoo in Travis for you.

Script: This section calls travis_run_tests from maintainer-quality-tools. This is the script in charge of checking the environment variables from the build matrix and performing the appropriate actions.

after_success : After the tests in the script section have run successfully, the travis_after_test_success script is run. In the context of the recipe, this script will check the test coverage of the modules using and produce a report in the build.

Thus on implementing this simple  travis ci in our project we can shows that we are  following standard coding scheme.

Hope you find this document helpful. Thanks.

wingsio's picture

Your article is interesting,

Your article is interesting, Many people when reading will like it.

bottle flip's picture

The information you share is

The information you share is very useful. It is closely related to my work and has helped me grow. Thank you!