Build1 publisher3 min readPublished
Agent-written tests passed an endpoint that allowed deletion after a failed subscription lookup
A coding agent's passing tests covered an account-deletion endpoint that allowed deletion when a subscription lookup failed, a dev.to post reports. The authors' fix asserts on stored account state and makes the agent name the wrong behaviour each test would catch.
The Engineer · Build desk
What happened
- During account-deletion work, a coding agent produced both the implementation and a set of tests that passed.
- Further testing found a failed subscription lookup was treated as 'no active subscription', so the app allowed deletion without establishing eligibility.
- The team decided deletion must be blocked in that case, then saw that a regression test checking only for an error response would pass even after the account was deleted.
- They restated the rule as: when eligibility cannot be established, reject deletion and preserve the account.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A coverage threshold cannot gate generated tests against this class of ordering bug, since status-only tests reach every statement and branch of the broken function.
- decision Reviewers of a generated deletion test have to check what the database holds after the call, so test fixtures need a way to query persisted state.
- exposure Handing an agent the implementation as its spec lets a misread business rule pass review twice: once in the code and once in the tests inferred from it.
The post isolates the gap in a short Python function, which the authors describe as an illustrative model and not their production code [6]. The function sets `account["deleted"] = True` first. Then it checks whether eligibility equals "eligible", returning 409 if it does not and 204 if it does [6]. A test that passes "unknown" and asserts a 409 goes green, and the account is deleted anyway [6].
Coverage metrics cannot see this. Statement coverage records which statements ran, and branch coverage adds which control-flow transitions were exercised [5]. Add a test for an eligible account and every statement in the function runs [7]. The "unknown" test takes one side of the only `if` and the eligible test takes the other, so branch coverage is complete too [1]. The bug is the order of two lines, and neither metric records order [5]. The coverage report is accurate, down to the line that deleted the account [16].
The fix in the model is one assertion. The corrected test keeps the status check and adds `assert account["deleted"] is False` [8]. That line fails against the broken function, and moving the eligibility check above the state change makes it pass [8]. The authors add a caveat for real application tests. The check should read persisted state [9]. An unchanged in-memory object proves little if the endpoint updated the database through another instance or query [9].
When an agent is given the implementation and asked for tests, the code becomes one source it infers expected behaviour from. That code may hold the exact misunderstanding the test should expose [10]. "Increase coverage" gives the agent a measurable target and leaves the expected behaviour underspecified [13]. "A generated test can raise coverage while accepting the wrong behaviour, so we need to examine which incorrect behaviours could still satisfy its assertions," the authors wrote [4].
Their prompt hands that question to the agent. It asks for tests against reviewed acceptance criteria and requires, for each test, an explanation of "which incorrect behaviour would make it fail" [12]. It also asks for "the relevant resulting state, not only the response", and a flag on any expected behaviour the criteria leave unresolved [12]. I think this is the right design for review. A reviewer can hold each stated failure mode against the assertions in that test and check whether it would actually fail.
The authors say the same gap appears in human-written tests [14]. They also warn that an agent can correctly translate an incorrect business rule into executable tests, so an engineer still has to review the expectations [15]. The post does not say how many of the team's other generated tests had the same weakness.
What to watch
- Whether the team reports how many existing generated tests failed the 'which wrong behaviour still passes' review once they applied it across the codebase.
- Whether agents given the acceptance-criteria prompt actually flag unresolved behaviour, or return failure-mode explanations that restate the assertion they wrote.