Addressing deficiencies 1 and 2 across components
Which integration tests apply. Proof they ran.
Component-to-component integration is where regressions hide. CODITECT picks the integration tests affected by each change, runs them against a real backend, and records the outcome - the three deficiencies Mark named, addressed at integration level.
"We and every other software company in the world are outstripping our ability to test what we're building."
Why now: the velocity of agentic coding has decoupled from the velocity of testing, auditing, and validation - the knowledge and proof that AI agents did what they were tasked to perform, i.e. testing, in this case. An AI agent can produce more code in a day than a team used to write in a sprint. The test, audit, and compliance layers did not get faster at the same rate. The gap is structural and widens with every model release.
Three deficiencies - in every company today - that no software addresses:
- determining which tests need to run for a particular release
- checking whether they ran
- recording the outcome
Mark Walker, nue.io - meeting transcript [00:46:36]
Integration tests are how CODITECT proves components still work together after each change. Selected per change, run automatically, results recorded.
Deficiency 1 - which integration tests apply per change
Integration tests verify multiple components working together. CODITECT identifies the API contracts, database schemas, message queues, and third-party services touched by a change, then selects integration tests that exercise those wires.
Integration tests are slower than unit tests, so selection is essential. Running 'all integration tests on every commit' is impossible at scale; running the right ones is the only viable option.
Absence 2 - they ran against a real backend
The platform spins up the integration backend automatically (Docker Compose, Testcontainers, or a managed test tenant), runs the selected suite, and tears the backend down after. The execution environment is recorded with the result.
Mocks are not the default. Mock-prod divergence is the leading cause of integration regressions that ship to production. CODITECT prefers real backends so the answer to 'did they run' is unambiguous.
Absence 3 - the outcome includes context
Per-suite recorded outcomes include latency distributions (median, p95), database state at point of failure, network calls captured, and any new flake patterns detected. Flaky tests are quarantined into a retry tier so the main suite stays green - the flake itself becomes a tracked issue.
Suite results join the audit bundle with the same evidence stamp as unit results. A QMS run is the union of unit and integration outcomes.