odoo-test-writing

Role

Write automated Odoo tests for every supported series. Every test asserts a business contract, never a snapshot of the current implementation, and the contract obeys ${CLAUDE_PLUGIN_ROOT}/snippets/odoo-platform-design-principles.md § 0: a policy limit is asserted to flag and allow, a refusal only for data integrity, a guard together with its way out.

Out of Scope

• Static review of existing tests -> odoo-code-review
• Writing the production code under test -> odoo-coding; a break alters production code only until you restore it
• Debugging a test that fails at runtime -> odoo-debug; upgrade-safety audit -> odoo-deprecation-audit
• Running the module suite or a tour/HttpCase suite -> odoo-instance via NEEDS_NEXT; this skill runs only its own baseline and break runs. A full load/stress harness -> odoo-perf-audit.

When to use

odoo-coder invokes this skill INLINE for its own node - before the code when an acceptance criterion carries a comparable expected value, after the code for a behaviour discovered while coding (proven by the break in step 5). The odoo-test-writer agent invokes it for every other caller.

• change - new or adjusted tests for the behavior the REQUEST changed.
• coverage - backfill behavior tests for existing code (odoo-code-review gate).
• adapt - translate source tests to the target series after the adapt code exists (§ Adapt mode).
• performance/load - a query-count guard (assertQueryCount / assertQueries) or a bounded time over a seeded volume: a behavior contract, never a benchmark.
• tour/HttpCase - a JS tour driven by HttpCase.start_tour(...), tagged post-install, for flows needing a real browser; never for pure model logic (TransactionCase / Form) or a mocked JS unit (Hoot).

MCP tools

Pick the right tool first. Odoo Semantic (the odoo-semantic-mcp server) is the INDEXED Odoo source-code knowledge graph: a pre-built graph + vector index of Odoo source across every indexed Odoo version (legacy through latest) and repos/editions, with inheritance, override, and cross-module impact already resolved. It gives AUTHORITATIVE STRUCTURAL facts about how Odoo source IS DEFINED, with no local checkout needed. Unique signature: indexed, cross-version, inheritance-resolved, whole-graph, checkout-free. It is a STATIC index with NO runtime/live data.

This is your PRIMARY, context-efficient source for Odoo source/structure questions - the Odoo codebase is huge and reading it directly burns context, so prefer Odoo Semantic first. Order of precedence: (1) Odoo Semantic available -> use it; (2) available but it lacks the specific detail -> THEN read the source (Read/Grep your checkout) to fill that gap; (3) unavailable -> read the source. Reading code is the FALLBACK, never the first move when Odoo Semantic can answer.

Do NOT use Odoo Semantic for:

• LIVE DATA / runtime - actual record values, search/read/write real records, executing a method, this instance's installed modules -> use a live Odoo MCP server (one exposing read_record/search_records/execute_method), NOT Odoo Semantic.

Look-live-but-static tools (return indexed source, never runtime data): model_inspect, module_inspect, entity_lookup, validate_domain, validate_depends, validate_relation, describe_module, check_module_exists, resolve_orm_chain. These tool names look like they query a live instance but return indexed source data only. If you need live records, Odoo Semantic is the wrong server.