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 は、すべてのグリーンの後にリファクタリングするように自分自身を訓練することによってベスト プラクティスを実行するのか、それともより多くの要件が表面化するまでステップを遅らせるのがより効果的なのか?