## 01、痛点

先讲一个真实场景。团队最近用 WorkBuddy 开发订单中心，需求是“取消订单”。需求文档写着：已支付订单不能取消，待支付订单可以取消。听起来很简单。我们让编程助手直接生成实现，几秒钟就出了代码。我 review 一遍，代码结构清晰，字段判断也有，就提交了。结果测试环境一跑，发现已支付订单照样能取消。问题出在助手生成的代码只判断了订单状态是否等于“待支付”，其它状态一律放行，而测试环境里那笔订单是“已支付”。如果没有自动化测试，这种缺陷要么靠人眼盯，要么靠线上用户发现。更麻烦的是，后续改库存释放逻辑，又把取消校验改坏了一次。

这就是当前很多团队面临的情况：生成代码很快，验证代码很慢；看起来对的代码不一定能跑；改一处逻辑，其它地方悄悄坏掉。根本原因是缺少一个稳定、快速、可重复的反馈环。人工 review 只能抓风格问题，很难每次覆盖边界条件；手动点界面又太慢，回归一次成本很高。于是代码越多，心里越没底。订单取消只是一个小功能，但缺反馈的问题会放大到整个系统。

## 02、是什么

TDD 并不神秘，它就是把开发过程拆成三步：红灯、绿灯、重构。红灯是写一个会失败的测试，表达你期望的行为；绿灯是写刚好让测试通过的最少代码，不额外设计；重构是在测试保护下整理结构，去掉重复、提升可读性。然后把这三步循环起来，形成反馈环。很多人以为 TDD 就是“先写测试”，其实重点不是先后顺序，而是循环：失败、通过、整理、再失败、再通过、再整理。

放到 WorkBuddy 里，这个循环可以被固化成开发节奏。比如开发订单取消，不是先让编程助手写完整实现，而是先让它生成一个针对“已支付订单不能取消”的失败测试。测试运行失败，说明这条规则被真实地表达了；然后让助手写最少代码让测试通过；测试通过后，再检查代码结构，做必要重构。这个循环每跑一次，就完成一次“规则确认”。红灯是确认测试有效，绿灯是确认实现满足规则，重构是确认结构不会腐烂。

需要澄清：TDD 不等于测试工具，也不是 QA 的职责。它是一种开发方法，用可执行测试驱动出实现。测试在这里不是附属品，而是需求的另一种表达方式。

## 03、为什么

为什么在 AI 写码时代还要强调 TDD？因为自动编程工具没有可执行反馈时，本质上仍然在猜代码是否正确。这句话听起来有点抽象，拆开讲：模型生成代码依据的是海量代码和自然语言中学习到的概率分布，它知道“取消订单”通常会检查状态，但它不知道你们项目里“已支付不能取消”这条具体规则，更不知道这条规则在支付回调、退款、人工客服等多个入口都必须一致。没有测试，模型只是在生成“看起来合理”的代码；有了测试，判断就从语言概率变成了机器结果。

测试是机器给出的通过或失败，没有灰色地带。这个反馈对自动编程工具尤其重要。人可以边写边在脑子里运行一些场景，模型不行，它不会自己执行代码，也不会自动发现边界条件。只有测试运行器告诉它哪里红了，它才能在下一轮调整。换句话说，测试把“像不像正确”变成了“是不是正确”。

订单取消的例子特别典型。我们先写“已支付订单不能取消”的测试，运行后失败，说明测试真的在约束行为。然后让编程助手写最少代码，可能就是在取消函数里加一个状态判断，抛出一个业务异常。再跑测试，通过。这一瞬间，我们不再靠肉眼判断代码是否正确，而是有了一条机器可重复验证的规则。后续无论怎么重构，只要这条测试还绿，规则就没有被破坏。

TDD 还解决了一个协作问题：测试用例就是可执行的需求文档。你不需要反复用自然语言解释“已支付订单不能取消”，因为测试代码已经把这条规则钉死了。新成员或自动编程助手接手时，先跑测试就能理解边界。

## 04、架构

从架构角度看，TDD 反馈环可以分为三层：规则层、实现层、反馈层。规则层由测试用例组成，表达业务约束，比如“已支付订单不能取消”。实现层是具体业务代码，比如订单取消服务。反馈层是测试运行器，它把规则层和实现层连接起来，输出红灯或绿灯。重构则是在三层之外加了一个守护：每次重构后，反馈层必须仍然是绿灯。

在 WorkBuddy 里，这个架构可以落成一条清晰的链路：先由需求生成规则层测试，再由测试驱动实现层代码，最后由反馈层自动运行全量测试。这个过程不依赖某个人记得所有细节，也不依赖口头交接。

这里有一个关键设计：测试应该绑定业务行为，而不是绑定实现细节。如果测试只通过公共接口验证结果，实现层就可以自由重构；如果测试频繁检查内部方法是否被调用、私有字段是否被修改，那么每次实现调整都会让测试变红，导致重构变成灾难。比如订单取消测试，比较好的做法是调用取消接口，验证订单状态和异常；而不是去断言内部一定调用了风控接口或库存接口。前者是行为验证，后者是实现绑定。

架构上还要注意反馈速度。测试越快，循环越短，自动编程助手迭代越高效。因此单元测试和轻量级集成测试优先，慢吞吞的端到端测试可以放到后续阶段。稳定、快速、可自动运行，这才是真正的反馈环。

## 05、实战

下面用一个 Python 小例子走完整流程。需求只有一条：已支付订单不能取消。先写失败测试：

```python
import pytest
from order import Order, OrderStatus, OrderCancelError

def test_paid_order_cannot_be_cancelled():
    order = Order(id='ORD-1001', status=OrderStatus.PAID)
    with pytest.raises(OrderCancelError):
        order.cancel()
```

这段测试在 order 模块还没实现时运行，会失败：可能是 ImportError 或 AttributeError。这就是红灯。接着写最少代码让测试通过：

```python
class Order:
    def __init__(self, id: str, status: OrderStatus):
        self.id = id
        self.status = status

    def cancel(self):
        if self.status == OrderStatus.PAID:
            raise OrderCancelError('已支付订单不能取消')
```

再跑测试，通过。绿灯达成。现在代码还可以，但规则直接散落在 cancel 里，后续可能有退款、风控等逻辑。我们做一次重构，把“能否取消”的判断抽出来：

```python
class Order:
    def __init__(self, id: str, status: OrderStatus):
        self.id = id
        self.status = status

    @property
    def can_cancel(self):
        return self.status != OrderStatus.PAID

    def cancel(self):
        if not self.can_cancel:
            raise OrderCancelError('已支付订单不能取消')
```

跑测试，仍然通过。这就是重构：结构变了，行为没变，测试保护了规则。接下来再加一条规则：待支付订单可以取消。先写失败测试：

```python
def test_pending_order_can_be_cancelled():
    order = Order(id='ORD-1002', status=OrderStatus.PENDING)
    order.cancel()
    assert order.status == OrderStatus.CANCELLED
```

当前实现 cancel 只对已支付抛异常，但待支付订单调用后状态不会变成已取消，测试会失败。然后补充实现：

```python
    def cancel(self):
        if not self.can_cancel:
            raise OrderCancelError('已支付订单不能取消')
        self.status = OrderStatus.CANCELLED
```

测试通过。这个循环很小，但完整展示了红、绿、重构。真正的好处不在这些小步里，而在于每一步都有机器反馈，不会出现“我以为可以了”的情况。

## 06、洞见

为什么说 AI 时代 TDD 的价值被重新放大？因为自动编程工具比人更需要稳定、快速、可自动运行的反馈。人写代码时，会基于经验、上下文和直觉做很多隐含判断；模型没有这些，它只能从输入里获取信息。如果输入只有一句“实现订单取消”，模型就会按常见模式生成代码，至于你们项目里“已支付不能取消”的特殊规则，它猜不对也正常。测试就是把这些隐含判断外化出来，变成机器可读的约束。

另一个洞见：测试让自动编程工具从一次性生成变成可迭代优化。你不需要一次把需求说得很完美，只要先给出测试，模型就能根据失败信息调整实现。失败堆栈、断言错误，都是具体的信号，比“你再看看”有用得多。红灯、绿灯、重构，其实是一套适合人机协作的节拍。

但同时要警惕一个误区：测试如果过度绑定实现细节，会让每次重构都变成测试灾难。比如你写了一个测试，要求内部先调用风险检查，再调用库存锁定，最后更新状态。后续把风控改成异步，或者把库存锁定合并，测试就会连环失败。失败的原因不是业务规则被破坏，而是测试管得太细。这样的测试不但帮不上忙，反而会锁死实现，让重构寸步难行。好的测试应该像合同，只规定结果，不规定手段。

## 07、行动

落到日常开发，我的建议是：规则明确的新功能优先 TDD，探索性原型不要机械套流程。具体可以这样做：

第一，动手前先问一句：这个功能的业务规则是否足够清楚？比如“已支付订单不能取消”，规则非常清楚，适合先写测试。如果是“做一个好看的订单详情页”，交互和视觉还在变，先写测试反而浪费。

第二，把规则翻译成失败测试，先看红灯。红灯不是形式主义，它是证明测试有效。如果测试不经任何修改就是绿的，很可能测试没有真正覆盖规则。

第三，写最少代码过绿灯，不做多余设计。不要顺手加一堆未来可能用到的扩展点，等测试逼出来再写。

第四，重构只在绿灯后进行。重构前先提交代码，重构后立即跑测试。如果测试红了，先回退或修正，不要让红灯过夜。

第五，探索性原型可以轻量 TDD。快速验证交互、性能、不确定性高的部分，等方向清晰后再补关键测试。探索阶段的目标是学习，不是永久的正确性。

第六，测试只绑定业务行为，不绑定实现细节。写完测试问自己：如果我把实现重写一遍，这个测试还会通过吗？如果不会，可能就绑得太死。订单取消测试只验证取消结果和异常，不关心内部调用顺序，这样以后换实现不用大改测试。

## 08、小结

TDD 的核心理念不是“先写测试”，而是把开发变成一个有机器反馈的循环：红灯、绿灯、重构。在自动编程工具普及的今天，这个循环不但没有过时，反而更重要。因为没有可执行反馈时，再强的生成能力也只是在猜；测试能把判断从语言概率变成机器结果。订单取消的例子虽小，但它说明了规则如何被测试钉死、实现如何被最少代码驱动、结构如何被测试保护。规则明确的新功能优先 TDD，探索性原型保持轻量，这是我认为最适合当下的落地方式。

## 09、链接与概念说明

TDD：测试驱动开发，用测试定义期望行为，再写实现使测试通过。

红灯-绿灯-重构：TDD 三步循环。红灯写失败测试，绿灯写最少代码通过，重构改善结构。

可执行反馈：测试运行器给出的通过或失败结果，是机器判断而非主观感觉。

回归测试：防止已有功能被修改破坏的自动化测试。

测试绑定实现细节：测试依赖内部方法、调用顺序或私有字段，导致实现调整时测试大量失败。

推荐阅读：Kent Beck《测试驱动开发》；Martin Fowler《重构：改善既有代码的设计》；Michael Feathers《修改代码的艺术》。

先讲一个真实场景。团队最近用 WorkBuddy 开发订单中心，需求是“取消订单”。需求文档写着：已支付订单不能取消，待支付订单可以取消。听起来很简单。我们让编程助手直接生成实现，几秒钟就出了代码。我 review 一遍，代码结构清晰，字段判断也有，就提交了。结果测试环境一跑，发现已支付订单照样能取消。问题出在助手生成的代码只判断了订单状态是否等于“待支付”，其它状态一律放行，而测试环境里那笔订单是“已支付”。如果没有自动化测试，这种缺陷要么靠人眼盯，要么靠线上用户发现。更麻烦的是，后续改库存释放逻辑，又把取消校验改坏了一次。

《WorkBuddy Skills 实战》第7招 测试先亮红灯

自动编程能力越强，越需要稳定快速的测试反馈。本文用订单取消案例走通红绿重构全流程，并给出 TDD 落地边界。

架构师

测试

开发工具

编程语言

TDD三步循环驱动AI写码：先写失败测试钉死业务规则，再生成最小代码通过，最后安全重构。用订单取消案例演示已支付禁取消、待支付可取消的完整流程。测试将判断从概率猜测变为机器验证，可自动回归防缺陷，测试只绑行为不绑实现细节。

人机协作

单元测试

集成测试

回归测试

代码解释

WorkBuddy 

Python

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《WorkBuddy Skills 实战》第7招 测试先亮红灯-腾讯云开发者社区-腾讯云

《WorkBuddy Skills 实战》第7招测试先亮红灯

《WorkBuddy Skills 实战》第7招测试先亮红灯

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《WorkBuddy Skills 实战》第7招 测试先亮红灯

《WorkBuddy Skills 实战》第7招 测试先亮红灯

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《WorkBuddy Skills 实战》第7招测试先亮红灯

《WorkBuddy Skills 实战》第7招测试先亮红灯