Do AI coding agents include enough tests before review?

Short answer: No. AI coding agents can draft tests, but they do not reliably provide enough coverage before review. Teams still need human checks, project rules, and CI to catch missing cases.

No. AI coding agents can draft tests, but they do not reliably provide enough coverage before review. Teams still need human checks, project rules, and CI to catch missing cases.

A pull request is built to carry code review and automated checks together. GitHub says pull requests are where you discuss changes, run automated checks such as tests and builds, and merge only after required reviews and checks are satisfied. GitLab’s review flow says the same thing in different words: reviewers inspect the change, test it, and check pipeline status before approval. That structure exists because code review without tests is weak, and tests without review are also weak.

The part people get wrong is assuming an agent that writes code also writes a complete test story. In practice, many agents produce the obvious happy-path tests and stop there. GitHub’s guidance on reviewing AI-generated code says to start with functional checks, make sure the code compiles, and verify that all tests pass. GitLab’s contribution rules also require proper tests and passing CI, and they explicitly say every new class should have corresponding unit tests. Those are baseline expectations, not a sign that the agent has already done enough.

The inconvenient part is that “enough tests” is not a property of the agent, it is a property of the repo and the change. A small refactor in a well-covered codebase may need only a narrow regression test. A change that touches branching logic, permissions, data migration, or API contracts may need unit, integration, and end-to-end coverage. GitLab’s review tutorial tells reviewers to test the code and then inspect the pipeline, including whether all expected tests ran, because a green pipeline can still be incomplete if the wrong tests ran.

AI agents are useful when they are constrained by standards. GitHub recommends combining human expertise with automated tools, and it says good DevOps practice is to have code automatically tested before merge and deployment. OWASP’s AI secure coding guidance also treats human review as a separate control and warns that AI-generated tests can still be trivial or misleading. That is the real failure mode: a test file exists, but it does not prove the behavior that matters.

The practical check is simple. Before review, ask whether the pull request contains tests for the changed behavior, the broken behavior, and the boundary conditions. Then ask whether the pipeline actually ran the relevant suite. GitHub’s pull request docs point reviewers to the Checks tab for automated tests and to the merge status for blockers and missing approvals. GitLab’s pipeline guidance adds a useful pattern: some projects run a predictive subset before approval and the full suite after approval, which means timing matters as much as content.

For AI-assisted work, the safest workflow is draft first, review second, ready for review last. GitHub supports draft pull requests for work in progress, and it says drafts are not ready for formal review. That is a better match for agent-generated changes than opening a finished-looking pull request that still needs human validation. If the agent has not added the right tests yet, the pull request should stay in draft until the missing coverage is written and the checks pass.

A concrete example makes this clearer. If an agent changes a billing rule from “allow on expired card for seven days” to “deny immediately,” a happy-path unit test is not enough. The review should also include a test for expiry on the boundary day, a test for existing subscriptions that renew under the old rule, and a pipeline run that proves the affected suite executed. Without those, the code may look complete while the real behavior still breaks. That is the kind of miss that reaches production and is hard to unwind.

The honest answer is that AI coding agents improve speed, not certainty. They can draft tests quickly, and sometimes they surface cases a person would miss. They do not replace a reviewer who knows the codebase, the risk profile, and the project’s required checks. If your standard is “enough tests before review,” the answer is no unless your own process makes it so.

For teams using DevConnect, the same rule applies. Use the agent to get to a draft faster, then make sure the pull request carries real tests, not just test-shaped output. DevConnect itself says it is free to use, which makes it a place to exchange review work instead of paying to skip the hard part. The hard part stays the same: a reviewer still has to confirm that the tests prove the change. https://devconnectplatform.com?ref=devto

FAQ

Should I trust an agent-generated test file if CI is green

No. Green CI means the checks that ran passed, not that the right checks ran or that the tests cover the real risk.

Should AI agents write unit tests, integration tests, or both

They can draft either, but the needed mix comes from the change itself. Logic changes often need unit tests, contract changes need integration coverage, and user-facing flows often need end-to-end checks.

What is the biggest missing piece in AI-generated tests

Boundary cases. Agents often cover the obvious success path and miss failures at the edges, like empty input, permission boundaries, retries, and version mismatches.

When is a pull request ready for review

When the code is in draft or ready state, the relevant tests exist, and the pipeline shows the checks that matter for the change have actually run.

Can a reviewer rely on code ownership rules instead of tests

No. Code owners help route review to the right people, but they do not replace test coverage or pipeline validation.

What should I ask an AI agent to add before I request review

Ask for tests tied to the changed behavior, a regression test for the bug that was fixed, and the narrowest additional coverage needed to prove the change.

Frequently asked

Should I trust an agent-generated test file if CI is green

No. Green CI means the checks that ran passed, not that the right checks ran or that the tests cover the real risk.

Should AI agents write unit tests, integration tests, or both

They can draft either, but the needed mix comes from the change itself. Logic changes often need unit tests, contract changes need integration coverage, and user-facing flows often need end-to-end checks.

What is the biggest missing piece in AI-generated tests

Boundary cases. Agents often cover the obvious success path and miss failures at the edges, like empty input, permission boundaries, retries, and version mismatches.

When is a pull request ready for review

When the code is in draft or ready state, the relevant tests exist, and the pipeline shows the checks that matter for the change have actually run.

Can a reviewer rely on code ownership rules instead of tests

No. Code owners help route review to the right people, but they do not replace test coverage or pipeline validation.

What should I ask an AI agent to add before I request review

Ask for tests tied to the changed behavior, a regression test for the bug that was fixed, and the narrowest additional coverage needed to prove the change.

Sources

• About pull requests - GitHub Docs
• Review AI-generated code - GitHub Enterprise Cloud Docs
• Tutorial: Review a merge request - GitLab Docs
• Merge request reviews - GitLab Docs
• Merge request workflow - GitLab Docs
• Maintaining codebase standards in a GitHub Copilot rollout - GitHub Docs

Originally published at devconnectplatform.com, where it is kept up to date.