私はサーバー側の開発にTDDを使用しています。すべての本番コードを単体テストで囲むことのメリットが、リファクタリングに必要な時間の4倍の時間を費やすことのデメリットを上回るかどうかはよくわかりません。
しかし、UIコードを開発しているときは、TDDを適用できません。そこにいるすべての原理主義者にとって、TDDの最初の法則は、「失敗した単体テストを書くまで、本番コードを書くことはできない」と述べています。しかし、UIを開発している場合、これはどのようになりますか？
（Seleniumのような受け入れテストフレームワークを使用できますが、ソースコードを直接操作しないため、カウントされません。）
それで、新しい> 90％のコードカバレッジポリシーのために、ユーザーインターフェイスコードを記述できないことをマネージャーに伝えることができますか？
TDDを作成すると、リファクタリングに4倍の時間がかかることがわかった場合は、より適切で分離されたテストを作成し、意図したとおりにテストで設計を推進する必要があります。また、テストなしでリファクタリングするときにデバッガーで費やす時間もカウントしていません。リファクタリングするときに発生するバグに他の人が費やす時間は言うまでもありません。
とにかく、ここにTDDがUI開発にとって何を意味するかについてのいくつかの良いアドバイスがあります。それがコードカバレッジにどの程度変換されるかは、UIフレームワークに大きく依存します。
絶対にあなたがそれをすることができないとあなたのマネージャーに言わないでください、彼はあなたをできる誰かとただあなたを置き換えるかもしれません。
TDDは、メソッドを分離してテストすることを目的としています。UIをテストする場合は、単体テストではなく統合テストを実行します。したがって、アプリケーションで関心の分離を慎重に行うと、あらゆる種類のプロジェクトにTDDを正常に適用できるようになります。
まず第一に、Robert Martin でさえUI に関するテストの課題を抱えています。
UI を TDD するときは、可能な限りアクションに近い「動作コントラクト」を記述します。理想的には、それは単体テストを意味します。しかし、一部の UI フレームワークではそれが非常に難しく、一歩下がって統合または「受け入れ」テストを使用して、UI がどのように動作するかを予測する必要があります。
単体テストが使えないとカウントされない？それは、スコアを維持するために使用しているルールによって異なります。「単体テストのみをカウントする」というルールは、「不定詞を分割しない」または「受動態を避ける」のと同じように、初心者が受け入れようとするのに適したルールです。最終的に、そのルールの境界がどこにあるかを学びます。あるポッドキャストで、Kent Beck は、必要に応じて単体テストと統合テストを組み合わせて使用することについて語っています (私の記憶が正しければ、Kent Beck は気にしないと付け加えています)。
また、TDD が目標である場合は、最初に Selenium テストを作成することが最も確実ですが、それでは処理が遅くなる可能性があります。私は、Selenium RC を使用して大きな効果を上げたいくつかのプロジェクトに取り組みました (そして、テストの実行速度が非常に遅いため、大きな苦痛を伴いました)。
フレームワークが何であれ、Google で検索して、同じ戦いを経験した人々から TDD のヒントを得ることができます。
このポリシーは少し不自然に聞こえますが、UI には単体テストではなく機能テスト ケースが必要であるという答えには同意します。しかし、どちらが先かという点には同意しません。私は、UI が開発される前に UI の機能テストを書かなければならない環境で働いたことがありますが、UI が非常にうまく機能することがわかりました。もちろん、これは、事前にいくつかの設計作業も行っていることを前提としています。テスト ケースの作成者と開発者が設計に同意している限り、コーディングを開始する前に誰かがテスト ケースを作成することは可能です。次に、コードはすべてのテスト ケースに合格する必要があります。基本的な原則は同じですが、法律に厳密に従っていません。
ユニットテストはUIコードには不適切です。UIのテストには機能テストが使用されますが、最初に機能テストを実行することはできません。90％を超えるコードカバレッジポリシーがUIコードもカバーしているかどうかについては、マネージャーに確認する必要があります。もしそうなら、彼はおそらくその動きを真剣に再考する必要があります。
ビジネスロジックをUIから分離し、UIコードが全体の10％未満になるようにしますか？関心の分離はTDDの主な目標であるため、実際にはそれは良いことです。
90％のカバレッジが行く限り...まあ、最善のコースは現存する文献をレビューすることです（私はケントベックとボブマーティンに焦点を当てます）、そしてあなたは無意識のカバレッジパーセンテージに従わないためのサポートを見つけると思います（実際には、ボブおじさんが最近これについてブログ記事を書いたと思います）。
スマート開発者は1回のテストで100％のカバレッジを取得できるため、コードカバレッジが90％を超えるのは馬鹿げています。;）
WPFを使用している場合、MVVMパターンを使用すると、UIコードをテストできます。UIコードをテストするということは、ModleViewをテストできるということですが、XAMLをテストできることは私が知っていることではありません。
フィリップの本を読む