Most developers treat ERP testing as an afterthought. You build a module, manually click through the UI, and ship it. That works fine when you have one module and two developers. It falls apart completely when you have twenty modules, shared business logic, and a client who needs to go live in three weeks.
The problem isn’t that people don’t know they should test. It’s that ERP systems are genuinely hard to test well. Data dependencies between modules, complex permission layers, async operations, schema changes that ripple across the system. A test suite that works for a simple CRUD app doesn’t map cleanly onto something like this. So let’s talk about what actually does work.
Why Standard Testing Advice Fails for ERP
Most testing guides are written for stateless APIs or simple web apps. Arrange some data, call an endpoint, assert a response. Clean and simple.
ERP systems don’t behave that way.
A sale in your Sales module touches inventory levels, triggers an accounting entry, updates a customer record in CRM, and might kick off a warehouse fulfillment task. Testing any of those pieces in isolation tells you almost nothing useful. But testing all of them together on every commit makes your CI pipeline a slow, expensive nightmare.
The real challenge is figuring out the right boundaries. Where do you draw the line between a unit test, an integration test, and a full end-to-end test? And how do you keep those boundaries from collapsing the moment someone adds a new module dependency?
The Three Layers That Actually Matter
Forget the traditional testing pyramid for a minute. For ERP systems, I think about it in three practical layers.
Business Logic Layer (Pure Unit Tests)
This is where your domain rules live. Tax calculation logic. Inventory reservation policies. Credit limit checks. These should be completely isolated from the database, the framework, and any other module.
If your business logic is tangled up with ORM calls or HTTP requests, you have a structural problem. Pull the logic out. Make it testable in pure Python with no dependencies. These tests should run in milliseconds and you should have a lot of them.
The benefit is more than just speed. When a pure logic test fails, you know exactly what broke. There’s no database state to blame, no async timing issue, no missing fixture. The rule was wrong or the code implementing it was wrong. That’s it.
Module Integration Layer (Contained Integration Tests)
This is where most of the interesting testing happens for ERP. You’re testing a module’s behavior with a real database, real ORM calls, and real business logic. But you’re limiting the scope to a single module or a small, well-defined module boundary.
These tests care about things like: does creating an invoice actually generate the right ledger entries? Does a stock adjustment correctly recalculate available quantities? Does a CRM contact merge handle duplicate records without data loss?
The key here is test data management. Sloppy test data is the thing that makes integration tests fragile and slow. You want deterministic, minimal datasets for each test scenario. Not a giant seed that every test shares and randomly fails when someone modifies it.
This is also where module isolation matters architecturally. If your modules are genuinely decoupled (as they should be in a modular ERP design), you can stand up just the modules you need for a given test. That keeps these tests fast and focused.
Cross-Module End-to-End Tests (Selective, Not Exhaustive)
These are expensive. They require a full system running, realistic data across modules, and they’re slow to write and maintain. You don’t want hundreds of them.
What you do want is a small, carefully chosen set that covers your critical business workflows end-to-end. The order-to-cash flow. The purchase-to-pay cycle. Payroll run to accounting reconciliation. The workflows that, if broken, would be immediately visible to your client.
Treat these like smoke tests for your core workflows. They’re not meant to catch every edge case. They’re meant to tell you “the system is fundamentally working” before you deploy.
Testing Async Code in an ERP Context
This one trips a lot of people up. If your ERP runs on an async stack (which it should, for performance reasons), your testing infrastructure needs to handle async properly.
The naive approach is to just run async tests synchronously by forcing an event loop. That works until it doesn’t. You’ll get false passes on race conditions, missed errors from unawaited coroutines, and tests that pass locally but fail on CI.
A few things worth knowing:
Use a proper async test framework. pytest-asyncio or similar. Don’t fight it. The overhead is minimal and the correctness difference is significant.
Be careful about shared event loops between tests. If tests share a loop, state can leak between them in ways that are incredibly difficult to debug. Isolate where you can.
Test your async error handling explicitly. Async code fails silently more often than sync code. An unhandled exception in a background task might not surface in a way that fails your test. You need to explicitly check that errors are propagated and handled the way you expect.
For more context on why async matters in ERP systems at all, our post on Async Python in ERP: Why Blocking I/O Is Killing Your Throughput covers the performance reasoning. The testing implications follow directly from that architecture.
Handling Database State Between Tests
This is where most ERP test suites rot over time. Test A leaves some data behind. Test B makes assumptions that happen to be satisfied by that leftover data. Test B now passes for the wrong reason. Six months later someone changes Test A, Test B starts failing randomly, and nobody knows why.
The answer isn’t to just truncate tables between every test. That’s slow and it doesn’t solve the underlying problem of tests depending on implicit state.
Here’s what actually works:
Wrap each test in a transaction that gets rolled back. Your tests run against a real database but leave no permanent state. This is fast because rollbacks are cheap. It’s also reliable because each test genuinely starts from the same baseline.
Use minimal, explicit fixtures per test. Don’t maintain a giant shared dataset. Create only the data your test actually needs, inside the test or in a focused fixture. Yes, this means more setup code. It’s worth it.
Be deliberate about fixture scope. Some data (like system configuration, base roles, country lists) makes sense to load once per test session. Order data, customer records, transactions? Those should be per-test.
Watch out for ORM-level caching. Some ORMs cache query results at the session level. If your test reads a record, modifies it at the database level, then reads it again, you might be reading cached data. Know how your ORM handles this and account for it.
The Fullfinity ORM handles schema changes automatically, which means you’re not managing migration files between test runs. That’s one less source of test environment drift to worry about. But you still need to think about data state carefully.
Testing Permissions Without Going Insane
RBAC (role-based access control) is one of the most under-tested areas in ERP systems. Developers write a happy path test as an admin user and ship it. Then a client runs a workflow as a sales rep and hits a 403 they never expected.
You need a testing approach for permissions that doesn’t require writing a test for every role-action-resource combination (there are too many of those to maintain).
Instead, think about it in two layers:
Test the permission model itself. Does your access control layer correctly evaluate “can this role perform this action on this resource?” These should be pure logic tests against your permission rules. Fast, isolated, comprehensive.
Test integration points as representative user types. Pick two or three representative user personas (admin, standard user, read-only user) and run your integration tests as each of them. You’re not trying to cover every edge case here. You’re catching the obvious misconfigurations.
For a deeper look at how to structure permissions in a way that’s actually testable, the post on ERP Role-Based Access Control: How to Actually Design Permissions That Don’t Break When You Scale is worth reading before you write your first permission test.
Testing Module Interactions at the Boundary
When modules talk to each other in a modular ERP, the communication happens through defined interfaces. Events, service calls, shared models. The thing that breaks most often isn’t the modules themselves. It’s the boundary between them.
A few patterns that help:
Test the contract, not the implementation. When Module A calls something in Module B, write tests that verify the expected contract: what inputs Module B accepts, what it returns, what side effects it has. Don’t write tests that reach inside Module B’s internals from Module A’s test suite.
Use lightweight fakes for cross-module dependencies in unit tests. If you’re testing Sales module logic that triggers an Accounting entry, you don’t need a full Accounting module running to test the Sales logic. Use a simple fake that records what was called. Verify the real Accounting integration separately.
Test bi-directional dependencies explicitly. If Sales depends on Inventory and Inventory depends on Product, test that chain explicitly. Don’t assume it works because each piece works in isolation.
This kind of thinking is closely tied to how you architect module boundaries in the first place. If you’re still figuring out that architecture, Building a Multi-Module ERP With Modular Architecture: What Nobody Tells You covers the design decisions that make testing much easier (or much harder) depending on the choices you make.
The CI Pipeline Problem (and How to Not Hate It)
A test suite that developers stop running locally because it’s too slow isn’t a test suite. It’s a liability.
ERP test suites get slow for predictable reasons: too many database operations, too many cross-module integration tests, and no strategy for running a fast subset during development.
Here’s a practical structure that works:
Fast tests on every commit. Pure unit tests plus a small set of module-level integration tests. Should finish in under two minutes. Developers actually run these.
Full integration suite on PR merge. This is where your comprehensive module integration tests run. It can take longer (5-15 minutes is acceptable) because it runs less frequently.
End-to-end smoke tests on deployment. Run these against a staging environment before any production deployment. They’re slow but they catch environment-specific issues that no other test layer would catch.
Label your tests clearly so you can run subsets easily. A test that’s hard to run selectively is a test that never gets run at all.
Common Mistakes Worth Avoiding
A few things I see repeatedly that cause serious problems:
Testing the UI instead of the business logic. Frontend tests are brittle and slow. Test your API and business logic thoroughly. Trust the UI tests to cover only what’s genuinely UI-specific.
Giant test fixtures shared across the entire suite. This starts as a convenience and becomes a maintenance nightmare. Keep fixtures focused and explicit.
No tests for failure paths. Happy path tests tell you the system works. Failure path tests tell you the system fails gracefully. For ERP, graceful failure matters enormously. What happens when an inventory reservation fails mid-transaction? Does the system roll back correctly?
Skipping multi-tenant test scenarios. If your ERP is multi-tenant, data isolation between tenants is a critical correctness requirement. You need specific tests that verify tenant A can’t see tenant B’s data. Multi-Tenant ERP Architecture: How to Actually Build It Without Painting Yourself Into a Corner covers the architecture side of this. The testing side follows the same logic.
Treating test data as production-safe. Test environments that share databases or configuration with production are disasters waiting to happen. Keep them completely separate.
Conclusion
Testing a multi-module ERP system well isn’t about having the most tests. It’s about having the right tests at the right layer, with clean data management and a CI structure that developers actually use.
The three things that matter most:
- Isolate business logic into pure functions that can be unit tested without any infrastructure. This gives you a fast, reliable foundation.
- Invest in focused integration tests with careful data management. These catch the real bugs that pure unit tests miss.
- Build a CI pipeline with distinct stages that balance speed for developers with thoroughness for deployment.
If you’re building on or evaluating Fullfinity, explore the platform features to understand how the modular architecture and zero-migration ORM shape what’s possible in your testing setup. And if you’re looking at the broader implementation picture, the blog has practical guides on the specific technical problems ERP developers actually run into.
