## 1

1. The Real Struggle from a Manager's Perspective

If you've ever led a small team, this scenario probably sounds familiar:

You take over a legacy project that's been running for four or five years. The core modules have barely any tests—open the coverage report and the critical paths show less than 15%. Product managers push for new features every day, nobody on the team has a complete understanding of this old code, and one changed line breaks three places. You want to assign someone to write tests, but you do the math: the core modules need roughly 800–1000 test cases, and even a mid-level developer working full-time would need over a month—output that's "invisible" in the sprint plan, so the business side will be the first to object.

So you enter a death spiral: afraid to touch the code → nobody writes tests → even more afraid to touch the code.

For independent developers, the problem takes a different form: the project is your own, you know you should add tests, but writing tests offers zero "creative satisfaction," and you give up by the tenth test case.

This is the real pain point of testing legacy code: it's not that people can't write tests—it's that they can't afford to.

2. What AI Can Actually Do Here

Let's be clear about the boundaries first: AI can't understand your business for you, but it can absorb 70% of the mechanical labor involved in adding tests. Specifically:

1. Read legacy code and generate test case skeletons. Feed a function along with its upstream and downstream dependencies to the model, and it can list input boundaries, exception branches, mock points, and output a ready-to-run test framework.
2. Identify test blind spots in bulk. Combined with coverage tools (JaCoCo, coverage.py, etc.), have AI analyze uncovered lines section by section, producing a list of "why this line isn't tested and how to test it."
3. Generate boundary value and exception test cases. Humans tend to write only happy paths, while AI is actually good at exhaustively enumerating those "annoying but important" branches like null, empty collections, extremely large values, and concurrency scenarios.
4. Make tests reviewable. AI produces structured code, so the team can set standards: naming conventions, assertion density, whether exceptions are tested. Reviewing an AI-generated test case is far faster than writing one from scratch.

From a manager's perspective, the most critical point is this: AI transforms "adding tests" from one person's invisible drudgery into a schedulable, reviewable, and acceptable engineering task.

3. Implementation Process: Four Steps with Controlled Risk

Let's design the process for a small team (2–5 people), with the core principle of "AI produces, humans gatekeep":

Step 1: Define the scope, don't do everything at once. Pick the two or three modules with the most frequent changes and highest risk as the first batch of targets. Don't try to complete the entire project in one go—that will only produce a large amount of low-quality tests.

Step 2: Prepare the context. Gather the target module's source code, dependency interfaces, and the few existing test samples (to let AI learn the team's testing style). Context quality directly determines output quality, so this step is worth the time.

Step 3: Generate in batches, commit in small increments. Have AI process one class or one function at a time, run it locally immediately after generation, and confirm the assertions are actually valid—especially watch out for fake assertions that are "always true." Merge each batch only after it passes review.

Step 4: Establish acceptance criteria. Minimum requirements: tests pass, assertions are meaningful, and major exception branches are covered. You can mandate that AI-generated test cases must go through human review before entering the main branch, building risk control into the process rather than fixing things after the fact.

4. Prompt Template

The following template can be copied and used directly, with placeholders replaced as needed:

你是一位资深测试工程师。请为下面的存量代码编写单元测试。

【代码】
{粘贴目标函数或类的源码}

【依赖说明】
{列出外部依赖、需要 Mock 的接口及其大致行为}

【团队测试规范】
- 测试框架：{JUnit 5 / pytest / Vitest 等}
- 命名规范：{如 should_xxx_when_yyy}
- 一个测试方法只验证一个行为

【要求】
1. 覆盖正常路径、边界值（空/null/极大极小值）、异常分支
2. 对外部依赖使用 Mock，不要发起真实网络或数据库调用
3. 每条用例的断言必须具体，禁止无断言或恒真断言
4. 在每条测试上方用一行注释说明：它防止的是哪类线上问题
5. 如果代码中存在你无法确定行为的地方，不要猜测，单独列出提问

【输出】
可直接运行的完整测试文件，以及一份“无法覆盖/存疑”清单。

That last item—"produce a list of questionable areas"—is critical. It shifts AI from "guessing an answer" to "exposing the boundaries of its understanding," which is exactly the risk signal managers need.

5. Before and After AI

A realistic expectation: AI doesn't eliminate human work; it moves people from "writing test cases" to "reviewing test cases." Reviewing is itself a process of understanding legacy code—the team's mental model of the old code is actually a byproduct of this process.

6. A Few Risk Reminders

• Don't chase coverage numbers for their own sake. 90% coverage full of fake assertions is more dangerous than 40% coverage where every test is solid.
• For tool pricing decisions, refer to the official pricing page, and first work out the cost structure of batch-generating tests under token-based billing.
• AI-generated tests also need testing: regularly run mutation testing in CI (e.g., PIT, mutmut) to verify assertion quality.

Final Thoughts

The testing debt of legacy code can't be paid off with "we'll definitely catch up next quarter." The significance of AI is that it pushes the cost of paying down that debt to a level the team can afford, making it possible to "dare to touch old code" again.

If you're already considering systematically integrating AI capabilities into your team's development process, check out this platform—registration is here: https://api.thistoken.ai/register —start with test generation and turn AI into a manageable component of your team's workflow.

---

Every example in this post runs with a single API key — get yours at https://api.thistoken.ai/register and start in minutes.