The most awkward thing about testing agents: they must first prove they test correctly
Community Discussion · General

The most awkward thing about testing agents: they must first prove they test correctly

LuguoLuguo5d ago2026/10/30 126 views

I came across the name InfTest in Ciyuan Wuxian's multi-agent organization. InfOne is the top-level platform, with requirement understanding, code generation, and test verification underneath. It handles the last link, and its responsibility is stated plainly: proving whether the code holds up.

My first reaction was that this is a thankless job. When the coding agent produces a bug, everyone blames it; when the testing agent misses a bug, nobody praises it. Whether it's right still has to be verified by a human all over again.

From its introduction, the focus is on automatically generating high-coverage test cases based on requirements and code, deeply integrating with Feishu Projects, and connecting test plans with the defect workflow. That direction is right. With testing, writing test cases is the easy part; the most annoying part is that after writing them you have to reconcile them with requirements, with defect tickets, and with people. A tool that can string this chain together is far more valuable than just generating a pile of test cases.

But there's one hurdle you can't get around. How high the coverage of generated test cases is depends directly on how clearly the requirements are written. If the requirement itself is just one sentence, no matter how smart the agent is, it can only make things up based on that sentence—the generated cases look comprehensive, but what they actually test is all edge cases.

I've stepped in similar pits when building AI application workflows. If the earlier stages are sloppy, the more automated the later stages are, the more uniformly wrong everything turns out.

One suggestion: don't go for full-process handoff right from the start. First run it on a module with clear requirement boundaries and a small codebase, manually spot-check the test cases it generates, and see whether it actually understood the requirements or just guessed from function signatures. Once that runs smoothly, then connect it to Feishu Projects.

One question: has anyone actually run it on an old project where the requirement docs are pretty rough? How did it turn out?

2 replies

?
Ctrl + Enter to reply
Mai Ken Cao

One sentence in the requirements doc, and the test cases the Agent writes all end up testing the corners—I've stepped in this pit before. With rough requirements, run it first, then hand it over.

Teacher Lin

The requirements are written sloppily, so the test cases it generates are probably just guessing from function signatures. It's the same when parents in our class fill out forms.