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 に答える