Deterministic tests, not guesses, UnitAutogen

An AI test guesses the answer. It cannot check it.

A language model writes the text of a test from patterns it has seen, not from your code. It never runs your function, so it has no source of truth for the expected value. It predicts a number that looks right. When the prediction is wrong, the test is wrong, and nothing in the model can tell you which tests those are.

How UnitAutogen generates a test

Derived from the branch predicate and the schema, not written as prose
Run against the real database, so a pass means the branch ran and the assertion held
The same tests, byte for byte, on every run, so diffs are reviewable and nothing flakes
A branch it cannot prove is marked with the reason, never turned green

What a language model produces instead

Plausible test text that can pass against an empty table or assert the wrong thing
Wrong a fraction of the time, and you cannot tell which without the oracle you were generating
Different output each run, so you cannot diff or trust the suite
Fails quietly, the worst failure mode for a test

The same function, two suites

Take a function that gives a 9 percent discount over 100.

CREATE FUNCTION apply_discount(p_total numeric) RETURNS numeric AS $$
BEGIN
  IF p_total > 100 THEN
    RETURN round(p_total * 0.09, 2);
  END IF;
  RETURN 0;
END $$ LANGUAGE plpgsql;

What a language model writes

-- guessed from the name, never run
SELECT is( apply_discount(150), 15.00,
  'gives 10% off' );
-- wrong. the code uses 9%, so this
-- reports a failure on correct code

SELECT ok( apply_discount(50) >= 0,
  'no negative discount' );
SELECT ok( apply_discount(150) IS NOT NULL,
  'returns a value' );
-- both pass for any number at all,
-- so they prove nothing

The one real assertion is a wrong guess, so someone loosens or deletes it
What is left is green and proves nothing
No branch was measured, the boundary at 100 is untested

What UnitAutogen writes

-- expected value read by running the
-- real function, both arms covered
SELECT is( apply_discount(150.00), 13.50,
  'over 100, the rate the code applies' );
SELECT is( apply_discount(100.00), 0.00,
  'at the boundary, nothing' );
SELECT is( apply_discount(100.01), 9.00,
  'just over the boundary, it applies' );
-- branch coverage 100%, and any test
-- that did not hold on a clean re-run
-- is dropped, never shipped green

The expected value is whatever your function actually returns, captured by running it
Both sides of total > 100 are driven, boundary included
A change that moves that behaviour fails the test before it ships

The expected value is not a claim that your code is correct. It is exactly what your code does today, pinned so a later change cannot move it unnoticed. That is the one thing a guessed number can never be.

How an AI-generated test fails, and why you cannot catch it

The false pass. An assertion loose enough to hold no matter what the code does, like ok(count(*) >= 0), stays green while the logic underneath is broken.
The wrong expected value. The model predicts the number from priors, not from your code, so a correct function reports a failure and a broken one can slip through.
Seed data that means nothing. Owner and tenant columns get a fixed or random id, never the identity the case is about, so an authorized-can-access test proves neither access nor denial.
Invented schema. It asserts on a column, function or constraint that does not exist, so the test errors out and is quietly removed to make the run pass.
No coverage. A model cannot tell you which branches it reached, so a green suite can leave half the logic dark.
Not reproducible. The same prompt yields a different suite next time, so you cannot diff it or trust that it still covers what it did yesterday.

The trap is the last one. To find the wrong tests in an AI-generated suite, you need the very oracle you were trying to generate, so every assertion has to be reviewed by hand. Scaling the model changes how often it is wrong, not that it is wrong, and never in a way you can locate. That is why the correctness core here is deterministic. A model still earns its place at the edges, naming a test, summarising a routine, triaging a flagged case, but never deciding whether a pass is real.

See the engine How coverage is measured Guardrail for AI-written code →

What platforms suggest

The platform points you to pgTAP tests that run against the real database.

Supabase ships pgTAP as its unit-testing extension, run against the real database. UnitAutogen's tests are derived from your code and run there, not guessed. Supabase, pgTAP unit testing →
Supabase encourages automated tests for your schema, functions and policies. UnitAutogen generates them, byte-for-byte reproducible. Supabase, Testing your database →

Generated from your code, not guessed by AI.