The uncomfortable truth about unit tests
Unit tests are one of the most effective quality practices in modern software development.
They are also almost entirely irrelevant to organisations that consume software rather than build it.
This is not a criticism of unit testing. It is a clarification of its purpose — and its limits.
What unit tests are designed to do
Unit tests exist to answer a very specific question:
- Does this piece of code behave as the developer intended?
They:
- Validate internal logic
- Execute in controlled environments
- Assume full access to source code
- Are written by those implementing behaviour
- They are inward-facing by design.
What software consumers actually need to know
Organisations consuming vendor or SaaS software need answers to different questions:
- Can our users still complete the workflows they rely on?
- Do end-to-end journeys still behave as expected?
- Did the last release break anything we depend on?
These are acceptance questions, not correctness questions.
The structural mismatch
Here is the core mismatch:
| Unit Tests | Software Consumers |
|---|---|
| Require source code | Do not have source code |
| Validate logic | Depend on behaviour |
| Developer-owned | User-owned risk |
| Component-level | Journey-level |
No amount of vendor unit testing can validate how your organisation uses the software.
The illusion of inherited assurance
- “If the vendor has good test coverage, we’re safe.”
This assumption is understandable — and wrong.
Vendor test coverage reflects:
- Vendor priorities
- Vendor assumptions
- Generic usage patterns
It does not reflect:
- Customer-specific workflows
- Cross-role journeys
- Operational dependencies
Acceptance failures are rarely unit failures
When acceptance breaks, it is rarely because:
- A function returned the wrong value
- A class behaved incorrectly in isolation
It is usually because:
- A sequence of steps changed
- A UI interaction behaved differently
- A dependency surfaced in a new way
These failures live between components, at the user journey level.
Why this gap keeps widening
- Consume more SaaS
- Accept faster release cycles
- Customise workflows through configuration
- Reduce internal testing teams
…the distance between unit correctness and operational confidence increases.
Unit tests improve software quality. They do not protect software consumers.
The necessary shift
- User journeys
- End-to-end behaviour
- Repeatable acceptance validation
Correctness is necessary. Acceptance is decisive.
Where VerityJX™ fits
VerityJX™ operationalises verifiable journeys by preserving user intent in a neutral contract and enabling those journeys to be executed — manually or automatically — against real systems, producing evidence a software consumer can own.
Read: Why VerityJX™ exists →Related insights
This article is part of a broader set of perspectives on acceptance, user journeys, and verification in vendor-supplied software.
Browse all insights →About the author
This article reflects the thinking behind VerityJX™ by UJX (User Journey eXplorer), focused on helping organisations verify the user journeys they depend on — even when they don’t own the software.