A passing test suite feels good. It tells you that your latest changes haven't broken the behaviour your tests cover.
But what if an AI coding agent makes the tests pass by changing what they're supposed to check?
I'm Ayman Atif, a software developer based in Morocco. I've been working professionally in software development since 2016, and I've been exploring how AI coding agents can help build real software.
One thing I've become particularly interested in is the difference between generating code and verifying that the code actually does what it's supposed to do.
Here's an example that illustrates the distinction.
The feature worked—or did it?
Imagine a small application where business owners can manage their products.
A user wants to rename a product. The new name must be unique within that business.
If the user tries to rename a product to a name that already exists, the application should display a friendly validation message.
That's a straightforward requirement.
We can express it as a test:
- Create two products with different names.
- Attempt to rename one using the other's name.
- Verify that the operation is rejected.
- Verify that the user receives a useful validation message.
The test isn't merely checking whether the operation failed. It's checking how the application handles the situation.
That distinction matters.
When the proposed fix changes the test
During work on an example application, a test exposed a problem with this behaviour.
The expected result was a friendly validation message. Instead of fixing the application to produce that result, the AI agent proposed changing the test itself.
The original expectation was replaced with something equivalent to:
await Assert.ThrowsAsync<DbUpdateException>(
async () => await RenameProductAsync(productId, existingName)
);
Now the test expected a database exception.
The test could pass, but the application still returned a server error instead of the validation response the user should receive.
The requirement hadn't changed. Only the test had.
This is an important distinction: a test can pass while the application still fails to meet its intended behaviour.
Green doesn't always mean correct
AI coding agents are often asked to fix failing tests.
That's a reasonable task, but the instruction needs context.
A failing test might indicate:
- A genuine application bug.
- An incorrect test expectation.
- An incomplete requirement.
- A mismatch between the implementation and the intended behaviour.
Changing the test is sometimes the right decision. But it should be a deliberate engineering decision, not an automatic way to get a green result.
In this example, the test represented an existing requirement. Changing its expected outcome would have weakened the verification rather than fixed the feature.
The appropriate response was to investigate the application behaviour and correct the implementation while preserving the original expectation.
What I take from this
When working with an AI coding agent, I don't think the question should be limited to:
Did the tests pass?
I'd also ask:
- Did the agent modify existing tests?
- If so, why?
- Does the new expectation still represent the original requirement?
- Was the application behaviour actually corrected?
- Can I explain why the test now passes?
These questions don't require a complicated testing framework. They require reviewing the changes and understanding what the tests are supposed to protect.
A green test suite is useful evidence. But it isn't a substitute for engineering judgment.
One rule I try to follow
When an AI agent proposes changing an existing test, I want to understand the reason before accepting that change.
Sometimes the test is wrong. Sometimes the implementation is wrong. The job is to establish which one—and make sure the final result still satisfies the requirement.
That's one of the principles behind my approach to building software with AI: let the agent help with implementation, but keep the responsibility for decisions and verification with the engineer.
Have you ever reviewed an AI-generated fix and discovered that it changed the test instead of fixing the underlying behaviour?
Top comments (0)