2

TDD 中的 Red、Green、Refactor (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 是最好的实践，是通过在每一次果岭后约束自己进行重构，还是延迟步骤直到更多需求浮出水面更有效？

4

1 回答 1

8
  • 重构每一个绿色。
  • 重构生产代码和测试代码。

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

于 2013-08-03T19:43:51.913 回答