Bricks Planet
返回砖块库

Brick Card

TDD red green refactor

可以先理解为:先失败测试再实现再重构的Agent约束

TDD red green refactor 是先写失败测试,再实现通过,最后重构整理的工程方法。放到 agent 语境中,它给 agent 一个清晰验证器,降低“看起来完成”的风险。

关键结构图

用自己的话表达讲给别人听卡住补理解
重新讲一遍

中心节点写「TDD red green refactor」,周围连接 Verification loop、validation gates、AI-ready Codebase,用细线表示相邻路径和调用方向。

What

TDD red green refactor 是先写失败测试,再实现通过,最后重构整理的工程方法。放到 agent 语境中,它给 agent 一个清晰验证器,降低“看起来完成”的风险。

When

当你要把「Coding Agent」从想法推进到可检查的动作时,可以调用「TDD red green refactor」。

How

先用一句话说明「TDD red green refactor」解决的判断问题,再把它连接到「Verification loop」等相邻砖,检查它在实际工作流里提供了什么证据或约束。

Examples

在复盘一个 Coding Agent 任务是否真正交付时,你可以用「TDD red green refactor」标记其中最需要被看见的结构,再检查它提供了什么证据、边界或行动方向。

在整理「Coding Agent」主题时,把「TDD red green refactor」和「Verification loop」放在同一路径里,可以帮助读者从单点概念走向可复用的判断框架。

来源

类型:工程实践 / 方法整理

事实线:这张卡把「TDD red green refactor」整理为实践方法: TDD red green refactor 是先写失败测试,再实现通过,最后重构整理的工程方法。

依据:1000 Bricks 本地砖块库的概念定义、相邻砖块关系和软件工程、代码代理和真实仓库协作讨论。

边界:适用于「Coding Agent 的真实工程任务、上下文、验证和交付」主题下的理解、复盘和设计判断;不等于行业统一标准或对所有场景都成立的结论。

常见误读:不要把它当作某篇材料的原文摘要,也不要因为概念名清晰就忽略具体情境和验证证据。