GroundRules: Skill for Claude Code

Odoo Test Writer

Use this skill to add practical tests for Odoo custom modules. Prefer tests at the Odoo behavior seam: ORM flows, constraints, computes, access rules, controllers, reports, forms, workflows, and integration boundaries.

First Move

Before writing tests:

• Identify the addon/module and target Odoo version.
• Inspect __manifest__.py, models/, views/, security/, controllers/, report/, static/src/, existing tests/, and relevant docs.
• If $ODOO_SOURCE is set, inspect local test helpers and framework behavior instead of guessing.

Choose The Test Type

• Use TransactionCase for most model/business-logic tests. Each test runs in a savepoint and rolls back.
• Use AccountTestInvoicingCommon for accounting tests needing companies, products, partners, taxes, journals, or invoices.
• Use Form helper when testing default values, onchanges, form validations, One2many/Many2many form behavior, or user-like form flows.
• Use HttpCase for browser, tour, website, portal, controller, or full UI flows.
• Use SingleTransactionCase only for read-only suites or expensive setup where cross-test state is acceptable.
• Use unittest.mock.patch/MagicMock for external APIs, payment gateways, OAuth, webhooks, file system, time, or slow services. Do not mock Odoo internals unless there is no better seam.

Required Structure

your_module/
├── __init__.py              # Do not import tests here
├── __manifest__.py
├── tests/
│   ├── __init__.py          # Import test modules here
│   ├── common.py            # Optional shared fixtures/helpers
│   └── test_*.py            # Test files

Every new test_*.py must be imported from tests/__init__.py, or the Odoo test runner will not discover it.

Writing Workflow

1. Map the behavior to prove and the smallest Odoo seam that proves it.
2. Add or update tests/common.py only for reusable fixtures/helpers.
3. Create fresh mutable records inside each test unless immutable setup belongs in setUpClass.
4. Use Arrange, Act, Assert sections in test method body.
5. Test happy path, validation/error path, and relevant side effects.
6. For access/security changes, test realistic users/groups/companies with with_user().
7. For external integrations, patch the boundary where it is used, then assert both state changes and mock calls.
8. For performance-sensitive code, add assertQueryCount when supported by the target version/test base.
9. Update tests/__init__.py and manifest dependencies only when evidence requires it.