How to Test AI Modules in Odoo (Mocking, Unit Tests)

Here is the blunt reality: most US-based Odoo development teams we audit have zero unit tests on their AI modules. Not “some tests.” Zero. And when that AI-powered invoice parser or demand forecasting module ships a wrong number, it corrupts accounting data across every affected record—and the cleanup alone costs $8,000–$40,000.

We’ve seen it happen across 150+ Odoo implementations at Braincuber Technologies. The pattern is identical every time. Developer builds a custom AI module—LangChain-powered chatbot, GPT-based document parser, ML forecasting model—tests it manually in dev, ships it. Three weeks later, it calls a dead API endpoint in production, or the AI returns an unexpected response format, and 2,400 records are corrupted.

That’s not an AI problem. That’s a test strategy problem.

Why AI Modules Break Differently Than Standard Odoo Code

Standard odoo development testing is painful enough. But AI modules introduce a second layer of failure modes that normal unit testing doesn’t catch.

When you call OpenAI’s API, Anthropic’s Claude, or any custom ML model from inside an Odoo module, you’re trusting an external system that can return a different response format than yesterday, throttle your request mid-workflow *(yes, even in production)*, or go down for 14 minutes while your warehouse confirmations queue up.

The testing pyramid model for Odoo AI modules breaks down like this:

Setting Up Your Odoo Test Module Structure

Before you write unit test code, the folder structure has to be right. Odoo auto-discovers tests only when the tests/ subdirectory follows this exact pattern:

your_ai_module/
├── models/
│   └── ai_invoice_parser.py
├── tests/
│   ├── __init__.py        ← must import all test files
│   ├── test_ai_parser.py
│   └── test_integration.py
└── __manifest__.py

Writing Unit Tests for AI Logic: The Mocking Strategy

Here’s where most developers get it wrong. They write unit tests that actually call the AI API. That’s not a unit test—that’s an api testing tutorial disguised as a test case.

A real unit test for AI logic uses unittest.mock to replace the AI call entirely. This is how you write testable code that doesn’t depend on OpenAI being available at 2 AM during your ci cd testing pipeline run.

from odoo.tests.common import TransactionCase
from unittest.mock import patch, MagicMock

class TestAIInvoiceParser(TransactionCase):

    @classmethod
    def setUpClass(cls):
        super().setUpClass()
        cls.vendor = cls.env['res.partner'].create({
            'name': 'Test Vendor',
            'email': 'vendor@example.com',
        })

    def test_ai_parses_invoice_amount_correctly(self):
        """Unit test: AI returns correct amount - mock the API call."""

        mock_ai_response = MagicMock()
        mock_ai_response.choices[0].message.content = \
            '{"amount": 4250.75, "vendor": "Acme Corp"}'

        with patch('your_module.models.ai_parser.openai.'
                   'ChatCompletion.create') as mock_ai:
            mock_ai.return_value = mock_ai_response

            invoice = self.env['account.move'].create({
                'move_type': 'in_invoice',
                'partner_id': self.vendor.id,
            })

            result = invoice.parse_with_ai(
                document_text="Invoice total: $4,250.75"
            )

            self.assertEqual(result['amount'], 4250.75)
            mock_ai.assert_called_once()

    def test_ai_handles_api_timeout_gracefully(self):
        """Negative testing: AI times out - module should NOT crash."""

        with patch('your_module.models.ai_parser.openai.'
                   'ChatCompletion.create') as mock_ai:
            mock_ai.side_effect = TimeoutError(
                "API timeout after 30s"
            )

            invoice = self.env['account.move'].create({
                'move_type': 'in_invoice',
                'partner_id': self.vendor.id,
            })

            # Should return fallback, not raise unhandled exception
            result = invoice.parse_with_ai(
                document_text="Invoice total: $1,200.00"
            )
            self.assertIsNotNone(result)
            self.assertEqual(
                result.get('status'), 'manual_review_required'
            )

This is the core principle of automated unit testing for AI: mock every external dependency, then test all the logic around the AI call.

Integration Testing: Where AI Meets Real Odoo Data

Once your unit test layer is solid, the next testing level is integration testing—specifically, confirming that your AI module’s output feeds correctly into Odoo’s accounting, inventory, or CRM models.

This is the test and integration phase where you test actual database interactions. Odoo’s TransactionCase rolls back every test’s database changes automatically, so you’re never writing dirty data to your dev database.

class TestAIInvoiceIntegration(TransactionCase):

    def test_ai_parsed_invoice_creates_journal_entry(self):
        """Integration test: AI output → journal entry in accounting."""

        mock_response = {
            'amount': 8750.00,
            'vendor': 'Acme Corp',
            'date': '2025-03-11'
        }

        with patch('your_module.models.ai_parser.'
                   'call_ai_service') as mock_ai:
            mock_ai.return_value = mock_response

            invoice = self.env['account.move'].create({
                'move_type': 'in_invoice',
                'partner_id': self.env['res.partner'].search(
                    [('name', '=', 'Acme Corp')], limit=1
                ).id,
            })
            invoice.auto_process_with_ai()
            invoice.action_post()

            # Verify journal entries with AI-parsed amount
            journal_lines = invoice.line_ids.filtered(
                lambda l: l.debit > 0
            )
            self.assertAlmostEqual(
                sum(journal_lines.mapped('debit')),
                8750.00, places=2
            )

Test Fixtures, Coverage, and CI/CD Pipeline

Test fixtures in Odoo solve the data duplication problem. Instead of creating a new vendor, product, and warehouse in every single test method, setUpClass creates the data once for the entire test class. That is the clean test approach—test data created once, used everywhere.

For python code coverage, run:

coverage run --source=your_ai_module \
  python -m odoo -c odoo.conf -d test_db \
  --test-enable -u your_ai_module

coverage report -m

For ci cd testing, every push to your Git repo should trigger a fresh Odoo test database, install the module with --test-enable, run tests, generate a coverage report, and fail the pipeline if test coverage drops below 80%.

The ci cd testing setup takes about 4 hours to configure and saves approximately 37 hours per quarter in manual regression testing across a typical 5-developer Odoo team. GitHub Actions, GitLab CI, or Jenkins all integrate with Odoo’s test runner using the same command.

(And yes, this applies to AI modules specifically—especially when you’re on OpenAI’s API and they push a model deprecation with 30 days notice. Your mock-based test suite catches incompatible response formats before they hit production.)

The Testing Strategy Your Team Is Missing

Look, write tests is advice you’ve heard before. Here’s what nobody tells you: the biggest gap in Odoo AI module testing isn’t the absence of tests—it’s the absence of a testing strategy that accounts for AI’s non-determinism.

AI responses are probabilistic. A test that calls a real LLM and checks for an exact string will fail randomly. That’s why your entire AI layer needs to be abstracted behind a service interface that your test code can mock cleanly. This is what makes code testable code vs. code that’s technically tested but brittle.

Frequently Asked Questions