测试驱动开发

哲学

核心原则：测试应该通过公共接口验证行为，而不是实现细节。代码可以完全改变；测试不应该。

好的测试是集成风格的：它们通过公共 API 练习真实的代码路径。它们描述系统_做什么_，而不是_如何_做它。一个好的测试读起来像规范——"用户可以使用有效购物车结账"告诉你确切存在什么能力。这些测试在重构中存活，因为它们不关心内部结构。

坏的测试耦合到实现。它们模拟内部协作者、测试私有方法，或通过外部手段验证（如直接查询数据库而不是使用接口）。警告信号：当你重构时测试失败，但行为没有改变。如果你重命名内部函数而测试失败，那些测试正在测试实现，而不是行为。

参见 tests.md 获取示例，mocking.md 获取模拟指南。

反模式：水平切片

不要先编写所有测试，然后编写所有实现。 这是"水平切片"——将 RED 视为"编写所有测试"，将 GREEN 视为"编写所有代码"。

这会产生糟糕的测试：