Prophecy-driven architecture presents a unique testing challenge: the core business logic depends on inputs that are delivered non-deterministically by an external oracle system, formatted in ambiguous natural language, and correct only when interpreted in a specific way that is not known until after the events they describe.
The first principle of testing prophecy-driven systems is that you must mock the oracle. A unit test that calls the real prophetic service introduces non-determinism, external dependencies, and the risk that the test inadvertently fulfills part of the prophecy by observing it, which collapses the distinction between test execution and production behavior.
Mock oracle design should produce prophecies that are specific enough to drive meaningful test coverage without being so literal that the test encodes a single interpretation. The standard pattern is a parameterized mock that accepts prophecy templates with controlled ambiguity levels, allowing the test suite to cover the full range of literal and figurative interpretation paths.
Assertions are structurally unusual in this domain. A standard unit test asserts that a function produces a specific output given a specific input. In prophecy-driven architecture, the output is partially determined by how the system interprets an ambiguous input, which means assertions must cover interpretation logic as a first-class concern rather than treating it as a passthrough.
Test isolation requires careful scope management. Prophecy-driven components tend to have side effects that extend beyond the function under test, because fulfilling part of a prophecy can trigger downstream components that were not intended to be in scope. Strict dependency injection and careful state management are prerequisites for meaningful unit coverage.
Edge cases include the null prophecy, where the oracle returns no prediction; the contradictory prophecy, where two simultaneously valid predictions conflict; and the self-referential prophecy, where the prediction describes the test run itself, which is a recursion risk that should be caught in the linting phase.
Code coverage metrics are misleading in prophecy-driven systems because high line coverage does not guarantee that all interpretive paths have been exercised. Branch coverage with prophecy-specific semantics, tracking both literal and figurative interpretation paths, is a more meaningful metric for this architecture.
Integration tests should use a contract testing approach with the oracle provider, verifying that the system handles all documented prophecy formats correctly without depending on the oracle's production availability. Consumer-driven contract tests maintained in a shared repository provide a stable integration boundary.
Test data management requires a curated prophecy corpus that covers the known input space without containing any prophecies that could cause problems if they escaped into a production log and were taken seriously by a superstitious DevOps team.
The CI pipeline should run the full unit test suite on every commit, with the mock oracle seeded from the curated corpus. Any test failure in the prophecy interpretation layer should block deployment, because a system that misinterprets prophecies in test will misinterpret them in production in ways that are difficult to hotfix after the fact.