The Generator
The only test generator that refuses to generate tests it cannot justify.
Most test generators focus on producing output.
SATE focuses on producing only what it can defend.
The Generator is a system for producing test candidates. It is designed to explore the behavioral surface of an application and propose hypotheses of behavior in the form of executable code.
/ It produces candidates.
/ It does not verify correctness.
/ It may infer patterns, but never knows authoritative truth.
“The Generator proposes. It does not decide.”
01 — Proof-Complete Discovery (No Guessing)
SATE does not scan folders. It maps reality through authoritative proofs.
Import-Aware & PSR-4 Authoritative
Discovery is fully import-aware and anchored to your composer.json PSR-4 mappings. SATE ignores unreachable code and orphaned files, focusing only on the executable surface that actually ships.
Explicit Route Expansion
Modern Laravel shortcuts like Route::resource are no longer a blind spot. SATE expands these into canonical REST actions, but only when both the controller and method are proven to exist. No heuristics, no guessing.
/ Conservative Mode: Only strictly proven surfaces.
/ Expanded Mode: Opt-in depth for comprehensive mapping.
/ Zero Heuristics: If it isn't in code, it doesn't exist.
02 — Why Test Generation Is Dangerous Without Coherence
A newly generated test can pass 100% of the time and still be wrong.
The Temporal Contradiction
In mature systems, behavior evolves. A test written years ago may assert behavior A, while a newly generated candidate asserts behavior B. Traditional generators maximize quantity—they produce behavior B and ignore the conflict.
If both would pass independently (due to a "silent fork" in the logic), you have introduced a contradiction that CI, coverage, and mutation testing are physically unable to detect.
Scenario: The Forked Truth
Existing Test (Manual):
Expects 200 OK
New Candidate (Generator):
Expects 302 Redirect
Result: SATE Audit FAIL
Both pass runners. SATE blocks the merge and materializes the contradiction.
03 — Nature of Output
If a generator never refuses, it is guessing.
SATE refuses by design.
Every output of the Generator is intentionally classified as a candidate. It is a starting point for verification, not a completed work, and is explicitly subordinate to the Auditor.
Expected Variance
Generated candidates may be logically incomplete, syntactically flawed, or factually wrong about the application's actual state. This is not a failure of the system; it is a byproduct of exploration.
Immediate Rejection
It is common and acceptable for candidates to fail audit immediately. These rejections are the primary mechanism for identifying where the application's behavioral surface is unanchored or contradictory.
Generate candidates anywhere. Verify them with SATE.
Candidates can be generated by any tool — SATE, AI assistants, framework tools, or written by hand. SATE decided which candidates deserve trust and become tests.
04 — Every Surface Gets a Verdict
SATE never looks away. Every discovered surface is tracked until it reaches a terminal state.
Executable Test
Behavior that is provable, stable, and justified is emitted as a first-class test.
Skipped with Proof
The engine identified the surface but found it lacks the explicit truth required for a non-guessing test.
Deferred with Reason
The surface is reachable but blocked by specific constraints (e.g., external side effects or dynamic dispatch).
Unreachable with Proof
A static path exists, but the engine has proven it cannot be triggered in isolation.
Materialized Failure Artifacts
When SATE refuses to generate a test, it does not leave you in the dark. Every non-executable verdict is materialized as a JSON Failure Artifact.
These are not logs—they are first-class, auditable outputs that live in your repository. They document exactly WHY a test could not exist and WHAT specific code changes are needed to make the behavior observable.
“Failure artifacts are tests in a different form — tests that expose problems in visibility, not just behavior.”
05 — Progress Transparency
SATE reports facts, not estimates.
Every percentage in the SATE console represents a deterministic phase milestone. We do not guess how long a run will take; we show you exactly which facts have been gathered and verified.
From Discovery to Emission, you always know the exact state of the engine. No "black box" behavior, no spinner-based ambiguity. UX exists to clarify, but it never affects the engine's audited truth.
06 — Knowledge Boundaries
The Generator operates under strict epistemic limits. It may infer patterns, but it never asserts truth. Every inference must be verified or it is reduced to a Failure Artifact.
KNOWN (INFERRED): Intent Patterns
The Generator can learn recurring intent patterns from existing code, tests, and structural signals. These patterns describe how developers tend to express intent, not whether that intent is correct.
Examples include:
- /Common shapes of meaningful Acts
- /Typical observable signals for a given domain
- /Repeated test structures historically associated with observability
These inferences are probabilistic and advisory only.
Explicit Ignorance
UNKNOWN (AUTHORITATIVE): Business Intent
Why a feature exists, what outcome is desired, or which behavior is correct is never known to the Generator.
UNKNOWN: Correct Behavior
Whether the application reflects truth, policy, or expectation is unknowable without execution and audit.
UNKNOWN: Risk Priority
Which behaviors are mission-critical versus incidental.
UNKNOWN: Risk Tolerance
The acceptable margin of failure in a given domain.
“Learned intent suggests where to look. Only observation decides what is true.”
07 — Trust Parity
SATE-Laravel enforces a policy of absolute equality under audit. No candidate is granted trust based on its origin.
Every candidate produced by the Generator must pass through the exact same verification gates as a hand-written test. They receive no exemptions from causality checks, observability rules, or strictness requirements.
“A generated candidate is just a hypothesis. Only the Auditor can promote it to a test.”
08 — Anti-Nepotism Doctrine
The Auditor has no memory of who proposed a candidate. It treats the Generator with the same level of suspicion as a human contributor.
There is no "privileged path" for system-generated code. If the Auditor identifies a contradiction between a new candidate and an existing test, that candidate is rejected without exception and materialized as a contradiction artifact. The authority of the audit layer is absolute and independent of the generation layer.
“Consistency is the first requirement of truth.”
09 — Tool vs Product
SATE-Laravel is a verification engine. The product is the Auditor. The ability to verify behavioral truth—and detect contradictions across the entire verification layer—is complete and functional without ever invoking the Generator.
Manual tests are first-class citizens. They are often the most valuable sources of evidence because they carry the weight of human intent—something the system can never replicate.
“The Generator may leverage learned patterns to propose candidates, but it has no authority to declare them valid.”
The Hierarchy
AUDITOR > GENERATOR
10 — Usage Caution
Generation is not a shortcut to knowledge. It is a method for exerting pressure on an application.
Do not use the Generator if you are still learning the application domain. You will not be able to distinguish between a valid behavioral rejection and a logical error in the candidate.
Do not use the Generator if your goal is simply to "increase coverage" quickly. The Auditor will reject the result, and you will have gained no truth.
“Generation amplifies inferred intent. If inferred intent is wrong, rejection scales.”
SATE does not aim to generate the most tests.
It aims to generate the most defensible ones.
When justification is not possible, generation is refused.