Testing and quality

Tests must prove business rules, permissions, migrations, and optional-module cooperation; building a wheel alone does not prove functional compatibility.

Learning objectives

• Run ModuleTestCase against a temporary database. When finished, verify the result with a test record and document ownership.
• Test valid and invalid states. When finished, verify the result with a test record and document ownership.
• Test companies, currencies, closed periods, and access rights. When finished, verify the result with a test record and document ownership.
• Install optional dependency combinations. When finished, verify the result with a test record and document ownership.
• Build and reinstall the wheel produced by CI. When finished, verify the result with a test record and document ownership.

Concepts to master

• Run ModuleTestCase against a temporary database.
• Test valid and invalid states.
• Test companies, currencies, closed periods, and access rights.
• Install optional dependency combinations.
• Build and reinstall the wheel produced by CI.

Guided practice

1. Activity 1. Run ModuleTestCase against a temporary database. Perform it in staging first, record preconditions, and compare expected and actual results.

2. Activity 2. Test valid and invalid states. Perform it in staging first, record preconditions, and compare expected and actual results.

3. Activity 3. Test companies, currencies, closed periods, and access rights. Perform it in staging first, record preconditions, and compare expected and actual results.

4. Activity 4. Install optional dependency combinations. Perform it in staging first, record preconditions, and compare expected and actual results.

5. Activity 5. Build and reinstall the wheel produced by CI. Perform it in staging first, record preconditions, and compare expected and actual results.

How to verify the result

• Company, user, language, time zone, and date match the scenario.
• Permissions allow only operations assigned to the responsibility.
• Changes are traceable and related documents remain consistent.
• The procedure is repeatable and has a documented correction path.
• A restored backup can reproduce the process without relying on production.

Common mistakes

• Confusing save with confirm, post, pay, or close.
• Testing only as administrator and assuming access rights work.
• Changing states or totals with SQL to bypass validation.
• Upgrading without inventory, restorable backup, and post-upgrade reconciliation.
• Documenting only the happy path while omitting cancellation, correction, and exceptions.

Developer perspective

Identify the models, fields, buttons, domains, and access rules involved. Before extending the process, locate the module that owns the rule, review its tests, and preserve invariants through super(). A correct customization must work across companies, languages, permissions, and states.

Production checklist

• Company, user, language, time zone, and date match the scenario.
• Permissions allow only operations assigned to the responsibility.
• Changes are traceable and related documents remain consistent.
• The procedure is repeatable and has a documented correction path.
• A restored backup can reproduce the process without relying on production.