refactoring - 红色、绿色、重构 : refactor after each test case, 还是充实整个测试套件？

Question

关于 TDD 中的红色、绿色、重构 (RGR) 工作流程的文章建议您在需要时通过编写“有罪的”代码来快速实现绿色(Kent Beck 举例说 TDD 中的“快速绿色为所有罪恶找借口”)，然后重构以改进设计。我不清楚何时最好执行重构步骤。

假设我正在制作 BookByIsbn REST 服务。我可能会按照以下顺序制作测试用例(仅供讨论)

"produces 404 (not found) if book does not exist"
"produces 400 (bad request) if isbn is invalid"
"returns 200 and entity if book found"
etc

RGR 的字面解释似乎暗示我在快速让每个测试用例变绿后进行重构。但这可能导致多次重构设计，而该设计在下一个测试用例中无效。我觉得将重构步骤延迟到整个测试套件为绿色时，当我完全了解服务必须执行的所有操作时，是执行 TDD 的更有效方法。

因此，问题是:RGR 的最佳实践是通过训练我们自己在每个果岭后进行重构，还是推迟该步骤直到更多的需求更有效地浮出水面？

Answer 1

• 重构每一个果岭。
• 重构生产代码和测试代码。

这确实意味着有时设计是非常短暂的。但这意味着代码始终是您当时对编码需求的最佳表达(测试，随着它们的增长)。