CtrlK
BlogDocsLog inGet started
Tessl Logo

odoo-automated-tests

Write and run Odoo automated tests using TransactionCase, HttpCase, and browser tour tests. Covers test data setup, mocking, and CI integration.

58

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/odoo-automated-tests/SKILL.md
SKILL.md
Quality
Evals
Security

Odoo Automated Tests

Overview

Odoo has a built-in testing framework based on Python's unittest. This skill helps you write TransactionCase unit tests, HttpCase integration tests, and JavaScript tour tests. It also covers running tests in CI pipelines.

When to Use This Skill

  • Writing unit tests for a custom model's business logic.
  • Creating an HTTP test to verify a controller endpoint.
  • Debugging test failures in a CI pipeline.
  • Setting up automated test execution with --test-enable.

How It Works

  1. Activate: Mention @odoo-automated-tests and describe the feature to test.
  2. Generate: Get complete test class code with setup, teardown, and assertions.
  3. Run: Get the exact odoo CLI command to execute your tests.

Examples

Example 1: TransactionCase Unit Test (Odoo 15+ pattern)

# tests/test_hospital_patient.py
from odoo.tests.common import TransactionCase
from odoo.tests import tagged
from odoo.exceptions import ValidationError

@tagged('post_install', '-at_install')
class TestHospitalPatient(TransactionCase):

    @classmethod
    def setUpClass(cls):
        # Use setUpClass for performance — runs once per class, not per test
        super().setUpClass()
        cls.Patient = cls.env['hospital.patient']
        cls.doctor = cls.env['res.users'].browse(cls.env.uid)

    def test_create_patient(self):
        patient = self.Patient.create({
            'name': 'John Doe',
            'doctor_id': self.doctor.id,
        })
        self.assertEqual(patient.state, 'draft')
        self.assertEqual(patient.name, 'John Doe')

    def test_confirm_patient(self):
        patient = self.Patient.create({'name': 'Jane Smith'})
        patient.action_confirm()
        self.assertEqual(patient.state, 'confirmed')

    def test_empty_name_raises_error(self):
        with self.assertRaises(ValidationError):
            self.Patient.create({'name': ''})

    def test_access_denied_for_other_user(self):
        # Test security rules by running as a different user
        other_user = self.env.ref('base.user_demo')
        with self.assertRaises(Exception):
            self.Patient.with_user(other_user).create({'name': 'Test'})

setUpClass vs setUp: Use setUpClass (Odoo 15+) for shared test data. It runs once per class and is significantly faster than setUp which re-initializes for every single test method.

Example 2: Run Tests via CLI

# Run all tests for a specific module
./odoo-bin --test-enable --stop-after-init -d my_database -u hospital_management

# Run only tests tagged with a specific tag
./odoo-bin --test-enable --stop-after-init -d my_database \
  --test-tags hospital_management

# Run a specific test class
./odoo-bin --test-enable --stop-after-init -d my_database \
  --test-tags /hospital_management:TestHospitalPatient

Example 3: HttpCase for Controller Testing

from odoo.tests.common import HttpCase
from odoo.tests import tagged

@tagged('post_install', '-at_install')
class TestPatientController(HttpCase):

    def test_patient_page_authenticated(self):
        # Authenticate as a user, not with hardcoded password
        self.authenticate(self.env.user.login, self.env.user.login)
        resp = self.url_open('/hospital/patients')
        self.assertEqual(resp.status_code, 200)

    def test_patient_page_redirects_unauthenticated(self):
        # No authenticate() call = public/anonymous user
        resp = self.url_open('/hospital/patients', allow_redirects=False)
        self.assertIn(resp.status_code, [301, 302, 403])

Best Practices

  • ✅ Do: Use setUpClass() with cls.env instead of setUp() — it is dramatically faster for large test suites.
  • ✅ Do: Use @tagged('post_install', '-at_install') to run tests after all modules are installed.
  • ✅ Do: Test both the happy path and error conditions (ValidationError, AccessError, UserError).
  • ✅ Do: Use self.with_user(user) to test access control without calling sudo().
  • ❌ Don't: Use a production database for tests — always use a dedicated test database.
  • ❌ Don't: Rely on test execution order — each TransactionCase test is rolled back in isolation.
  • ❌ Don't: Hardcode passwords in HttpCase.authenticate() — use self.env.user.login or a fixture user.

Limitations

  • JavaScript tour tests require a running browser (via phantomjs or Chrome headless) and a live Odoo server — not covered in depth here.
  • HttpCase tests are significantly slower than TransactionCase — use them only for controller/route verification.
  • Does not cover mocking external services (e.g., mocking an SMTP server or payment gateway in tests).
  • Test isolation is at the transaction level, not database level — tests that commit data (e.g., via cr.commit()) can leak state between tests.
Repository
administrakt0r/AI-Agents-Safe-Coding-Skills
Path

skills/odoo-automated-tests/SKILL.md

Commit

57c135b

Last updated
First committed

Also appears in

administrakt0r/AI-Agents-Safe-Coding-Skills
In sync

since Aug 19, 2026

administrakt0r/AI-Agents-Safe-Coding-Skills
In sync

since Aug 19, 2026

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.

Claim skill