祝融说。

Among all automated quality-assurance measures, automated testing is unquestionably the cornerstone of cornerstones. In the era of AI programming, its importance has been raised to an unprecedented, strategic level of life and death.

In the past, we wrote tests for our code primarily to "guard against our own mistakes" and to "make future refactoring easier." Today, the primary purpose of writing tests has shifted: it is to "draw an absolute, machine-verifiable behavioral baseline for AI."

Every unit test is a "micro-constraint" placed upon AI. In the language of code, it states precisely: "For this input, you must return this output." "After you perform this operation, the system state must change in this way." "If you receive this abnormal input, you must throw this specific error."

When hundreds or thousands of such "micro-constraints" converge, together they form a powerful "electric grid." AI can refactor and optimize freely and boldly within the safe zone enclosed by this grid. Yet if any single modification — even the change of one character — causes a deviation in some expected behavior, the grid immediately "energizes," sounding a piercing alarm through a failing test.

In this chapter, we will learn to stop treating testing as an afterthought appended only when coding is done. Instead, we treat it as a "safety net" that must be laid down before AI ever intervenes, guarding the core domain logic.

11.1 When AI Refactors Code, How Do You Avoid Breaking Existing Features?

One of AI's most impressive — and most frightening — abilities is large-scale code refactoring.

You can hand it a chaotic 500-line "monster" function and say, "Please refactor this function into several smaller, more cohesive functions and classes that follow the SOLID principles." Seconds later, it presents you with a fresh piece of code that looks well organized and structurally clear.

This looks like magic — but it could also be "dark magic." How can you be certain that this thoroughly "recut" new code is behaviorally 100% equivalent to the old code? How do you know that, amid all those dazzling "extract method" and "move field" operations, some small but critical piece of business logic was not "optimized" away by AI?

The answer is: without automated tests, you cannot know. You can only pray.

"Visual review" is nearly useless in this scenario. The human brain is extremely poor at performing fine-grained "behavioral equivalence" comparisons between two complex code structures that are similar in logic. We are easily misled by a new code's tidy "appearance" and overlook the subtle logical changes lurking beneath the surface.

The "Golden Coverage" Test Suite: A License for AI to Refactor

This is the new role that automated testing — especially unit testing — plays in the AI era: it becomes the "license" we grant AI to undertake large-scale refactoring.

Before we issue any "refactor" or "optimize" instruction to AI, we must first complete a prerequisite: write a high-coverage unit test suite for the target code that is about to be changed.

This test suite is like taking a "behavioral snapshot" of the old code before refactoring. It fixes, in the precise form of code, every known and important behavioral characteristic of the old implementation.

[A Concrete Refactoring Workflow]

Scenario: We have a legacy function calculateDiscount responsible for computing order discounts. It is riddled with nested if-else statements and hard to maintain. We want AI to refactor it.

The Wrong Workflow (Prayer-Based Refactoring):

1. Copy the code of the calculateDiscount function and hand it to AI.
2. Say: "Please refactor this function to make it cleaner."
3. AI returns a very elegant new version based on a "strategy pattern."
4. You give it a quick "visual" once-over, think it looks great, and replace the old code.
5. A week later, the finance department reports that every order in which "Diamond members" bought "digital products" during the "anniversary sale" has the wrong discount. You plunge into an endless hell of overtime.

The Right Workflow (Grid-Based Refactoring):

1. Step One: Lay the Grid. Before touching the refactoring, write comprehensive unit tests for the existing, ugly calculateDiscount function.

// calculateDiscount.test.js
test('Regular member purchasing regular items should receive no discount', () => { ... });
test('Gold member should receive 5% off', () => { ... });
test('Diamond member should receive 10% off', () => { ... });
test('During the anniversary sale, all items receive an additional 10% off', () => { ... });
test('Digital products do not participate in the anniversary sale discount', () => { ... });
test('Diamond member purchasing non-digital products during the anniversary sale should get a discount on top of a discount', () => { ... });
// ... cover all known business rules and edge cases

Run the suite and confirm every test passes. At this point, you now hold a "safety net" that protects the existing functionality.

2. Step Two: Authorize AI to Refactor. Now you can safely hand the calculateDiscount function to AI.

   "Here is our discount calculation function and its unit test suite. All tests currently pass. Please refactor the calculateDiscount function so that its internal implementation is cleaner and more extensible, without modifying any test files. The refactored code must still pass all existing tests."

3. Step Three: AI Works Within the Grid. AI receives the instruction and begins its "magic." It may refactor the original if-else chain into an elegant "rule engine" or "strategy pattern."

4. Step Four: Automated Acceptance. AI returns its refactored code. At this point, you no longer need to eyeball the complex logic line by line. The only thing you must do is swap in the new code for the old implementation, then — re-run the unit test suite.

5. Step Five: The Moment of Judgment.

   • If all tests still pass: congratulations. AI's refactoring is very likely behaviorally equivalent. You can merge the change with reasonable confidence -- while remembering that passing tests do not prove full equivalence; uncovered behaviors may still have changed.
   • If some test fails — say, Diamond member purchasing non-digital products during the anniversary sale... — the "grid" has sounded its alarm. It tells you precisely that, during the refactoring, AI missed or misread the subtle business rule that "digital products do not participate in the anniversary sale discount."

At this moment, you have intercepted a potentially catastrophic production bug. You never need to guess where the problem lies: the failing test, like a precise probe, has already pinpointed the defect. You can "feed back" both the failing test results and AI's new code, letting AI fix the very problem it introduced.

Conclusion: In the AI era, the value of testing has undergone a fundamental leap. It is no longer merely a "quality assurance" tool; it has become the core mechanism in human-machine collaboration for defining behavioral contracts, constraining AI's actions, and automatically accepting AI's output.

Write the tests first, then let AI refactor. This iron rule is your "talisman" for harnessing AI's formidable refactoring power without being consumed by it.

11.2 Turning Unit Tests into an Impassable Electric Grid (Hard Coverage Standards)

We already know why testing matters. But a careless test suite with gaps in its coverage is an "electric grid" riddled with holes — AI can easily slip through them and damage the functionality those tests never reached.

To make this "electric grid" genuinely effective, we must introduce rigid, quantifiable metrics to measure its "density" and "strength." The most fundamental and most effective of these is "code coverage."

Code coverage measures how much of the code under test is actually executed by your test cases. Common coverage metrics include:

• Line coverage: how many lines of business code did the tests execute?
• Branch coverage: how many if-else and switch branches did the tests cover (were both the true and false paths traversed)?
• Function coverage: how many functions did the tests call?

Among these, branch coverage is the most valuable, because it speaks directly to whether the "decision logic" inside the code has been adequately tested.

Setting a "Non-Negotiable" Coverage Gate

A coverage report alone is not enough. We must convert it into an automated, impassable "gate." Concretely, this means placing a "quality gate" in our continuous integration (CI) pipeline.

The gate's rule is brutally simple:

Any code submission that drives the overall code coverage — or the coverage of any core module — below a preset threshold (for instance, 85%) will cause the build to fail automatically, and the submission will be barred from merging into the main branch.

This rule applies equally to humans and to AI.

Why is this "hard standard" so important?

1. It eliminates excuses. Questions that are subjective and endlessly debatable — "Should we write tests?" "How far should the tests go?" — become an objective, black-and-white engineering standard. Below 85% simply is not acceptable, no exceptions.
2. It drives quantifiable results. It gives both us and AI a clear, measurable working target. Our task is no longer the vague "write some tests," but the explicit "raise coverage above 85%."
3. It gives AI the power to "check itself." Once AI finishes a code change, we can let AI run the tests and the coverage check itself. If coverage falls short, AI immediately learns that its work is "not up to standard" and must add more test cases. This relieves us of much of the burden of manually reviewing test completeness.

How to Collaborate with AI to Reach the Coverage Target?

With the gate in place, the next question is how to get there. Fortunately, AI itself is a tireless and exceedingly capable "test case writer."

[Instruction Template for Having AI Write Tests]

Your Prompt:

Context: We have a hard requirement that all new code must have at least 85% branch coverage. I have written the following function, but I haven't written any tests for it yet.

Your Role: Act as a meticulous QA Auditor with expertise in Test-Driven Development (TDD).

Code to be Tested:

// [Paste the business code you or AI just wrote]

Task:

1. Analyze the Code: Identify all logical paths, branches, and edge cases in the provided function.
2. Generate Test Cases: Write a comprehensive suite of unit tests using the [your test framework, e.g., Jest] framework.
3. Ensure Full Coverage: The test suite you write must aim for 100% branch coverage for the given function. For each if statement, you must provide at least one test case for the true path and one for the false path. For each error condition, you must write a test to assert that the correct error is thrown.
4. Explain Your Tests: Briefly comment on why each test case is necessary.

When executing this instruction, AI systematically analyzes your code, tracks down every if, else, for, while, and try-catch, and then, like someone driven by perfectionism, designs a matching test case for each and every logical branch. It is especially adept at handling the "edge cases" we so easily overlook — empty arrays, null inputs, division by zero, and so forth.

By fusing the rigid metric of "coverage" with AI's formidable ability to "generate test cases," we establish a virtuous cycle:

1. The CI gate fixes a non-negotiable quality floor.
2. AI becomes the most efficient instrument for reaching that floor.

This "test grid" is now dense, rugged, and endowed with the capacity to "repair and reinforce itself."

11.3 The Fatal Instruction: "Execute and Fix All Failing Tests"

We have laid the grid (written the tests) and fixed the gate (coverage standards). Now let us learn how to use this grid most effectively to "constrain" and "drive" AI's day-to-day development work.

One revolutionary instruction — to be used with care — is to authorize AI to "execute and fix" failing tests.

The power of this instruction is that it converts what once required flesh-and-blood intervention in the "debugging loop" into a "self-consistent loop" running entirely inside AI.

The Traditional Debugging Loop (Human-Driven):

1. AI generates code.
2. A human runs the tests.
3. Tests fail.
4. A human reads the failure logs.
5. A human analyzes the cause of the failure.
6. A human tells AI what is wrong and how to fix it.
7. Return to Step 1.

In this loop, the bottleneck is entirely in the human's ability to analyze and to translate that analysis into instructions.

AI's Self-Consistent Loop (Test-Driven):

1. AI receives a task (for example, "add a new feature").
2. AI modifies the code.
3. AI runs the tests itself.
4. Tests fail.
5. AI reads the failing test logs itself (error messages, failed assertions, stack traces).
6. AI analyzes the causal relationship between the failure logs and the code it just changed.
7. AI proposes a fix itself and produces new code.
8. Return to Step 3, and repeat until every test passes.

Do you see it? In this new loop, the failing test log has become AI's "teacher" and "commander." AI no longer needs us to "translate" the problem; it can learn and self-correct directly from the rawest, most objective "machine feedback."

How to Issue This "Fatal Instruction"?

This instruction is typically used to extend functionality or fix bugs in a system that already has a stable test suite.

[Instruction Template 11.1: Test-Driven Bug Fix]

Your Prompt:

Context: We have a bug in our system. I have already written a new unit test that reproduces this bug. This new test is currently the only failing test in our test suite.

Your Role: Act as a Senior Software Engineer practicing Test-Driven Development (TDD). Your goal is to make the failing test pass, without breaking any other existing tests.

Failing Test Code:

// [Paste the failing test case that reproduces the bug]

Relevant Business Logic Code:

// [Paste the business logic code related to the bug that needs to be modified]

Your Task (Iterative Process):

1. Analyze the Failure: Read the failing test and understand the discrepancy between the expected behavior and the actual behavior of the business logic code.
2. Propose a Fix: Suggest a minimal change to the business logic code that you believe will fix the issue.
3. Apply and Verify: I will apply your proposed fix and re-run the entire test suite. I will then give you the new test results (either "All tests passed" or a new list of failing tests).
4. Repeat: If tests are still failing, analyze the new results and propose another fix. Continue this loop until I tell you "All tests passed".

[Instruction Template 11.2: Test-Driven Feature Development]

Your Prompt:

Context: I want to add a new feature: "[briefly describe the new feature, e.g., support a 'buy one get one free' discount type]". I have already written the "scaffolding" for this feature, including a set of new unit tests — currently failing ("pending") — that define how this new feature should behave.

Your Role: Act as a Senior Software Engineer practicing TDD. Your task is to write the necessary business logic to make all the new pending tests pass.

New, Failing ("Pending") Tests:

// [Paste the failing test cases written for the new feature, which specify its behavior]

File to Modify: [Provide the file path and the existing code where the new logic is to be added]

Your Task: Your mission is to write the implementation code inside [filename] that satisfies all the requirements defined by the new tests. You must do this without breaking any of the existing tests in the suite. I will run the tests after each of your suggestions and provide you with the results.

Prerequisites and Risks

This pattern of "authorizing AI to repair itself" is immensely powerful, but it has its boundaries and its risks:

• Prerequisite: high-quality tests. The success or failure of this pattern rests entirely on the quality of your test suite. If your tests themselves harbor logical errors or leave coverage gaps, AI may write code that merely "passes the wrong tests" while still being logically wrong inside. Garbage tests in, garbage code out.
• Risk: falling into a "local optimum." AI may find a cheap, minimal code change that makes the current failing test pass, yet that change might not be an elegant, general-purpose solution.
• Your role: Within this loop, your role shifts from "micro-manager" to "final acceptance officer." You no longer need to tell AI "how" to do things — but when AI reports "all tests passed," you must conduct a higher-order final review of its "deliverable" (the code that passes all tests) through the lens of architecture and design principles, ensuring AI has not sacrificed the code's overall elegance merely to satisfy the tests.

Despite these risks, the "test-driven AI" model remains the most powerful paradigm we currently have — the closest thing we possess to "automated software development." It places AI's "black-box" code generation process inside a fully "white-box," precisely verifiable constraint framework, achieving an outstanding union of speed and quality.

[Configuration Template] Building the Test Grid for an AI Programming Project

To let you get started immediately and build this "test grid" for your own project, here is a configuration template and workflow based on a common JavaScript/TypeScript project.

Example Tech Stack:

• Test framework: Jest
• Coverage tool: Jest's built-in coverage (powered by Istanbul)
• CI/CD: GitHub Actions

Step One: Configure jest.config.js

In your Jest configuration file, enable coverage collection and set the "gate."

// jest.config.js
module.exports = {
  // ... other config ...

  // Enable coverage report generation
  collectCoverage: true,

  // Specify which files to gather coverage from
  collectCoverageFrom: [
    'src/**/*.{js,jsx,ts,tsx}',
    '!src/**/*.d.ts',
    '!src/index.ts', // Exclude entry files, etc.
  ],

  // Directory where coverage reports are written
  coverageDirectory: 'coverage',

  // [Core] Set the coverage quality gate
  coverageThreshold: {
    global: {
      branches: 85, // Global branch coverage must reach 85%
      functions: 85, // Global function coverage must reach 85%
      lines: 85, // Global line coverage must reach 85%
      statements: 85, // Global statement coverage must reach 85%
    },
    // You can set stricter requirements for specific, more critical modules
    './src/core/business-logic/': {
      branches: 95,
      statements: 95,
    },
  },
};

Step Two: Configure package.json Scripts

Add a dedicated script for running the tests together with the coverage check.

// package.json
{
  "scripts": {
    "test": "jest",
    "test:coverage": "jest --coverage"
  }
}

Now, when you run npm run test:coverage locally, if coverage comes up short, Jest will report an error and exit with a non-zero status code.

Step Three: Build the Automated Defense in GitHub Actions

Create the file .github/workflows/ci.yml at your project root.

# .github/workflows/ci.yml
name: CI & Quality Gate

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm install

      - name: Run tests with coverage check
        # The key is to run our script that includes the coverage check
        # If Jest exits in error because coverage falls short, the entire CI job fails
        run: npm run test:coverage

Configuration complete!

From this point on, any push to the main branch, or any pull request aimed at the main branch, automatically triggers this workflow. If your new code does not come with enough tests and coverage slips below the 85% gate you set in jest.config.js, GitHub Actions immediately shows a red "X."

That red "X" becomes an impassable "fence." Your team — you and your AI included — will be unable to merge any code that breaches the quality floor.

You have successfully turned a quality standard that once depended on "self-discipline" and "conscientiousness" into an automated, rigid, uncompromising engineering reality. This "test grid" now stands as the most loyal, round-the-clock guardian of your project's assets.