テスト運転のUIは、画面上に表示するまで、画面上で何をしたいか分からないことが多いため、問題があります。そのため、GUIの開発は大規模な反復的な傾向があり、したがってテストを実行することは非常に困難です。
これは、GUI用にTDDを放棄したという意味ではありません。むしろ、GUIからできるだけ多くのコードをプッシュし、単純な配線コードだけを残しています。この配線によって、問題の本質に影響を与えることなく、私たちが必要とする大規模な反復的な変更を行うことができます。
このテクニックは、数年前にMichael Feathersが"The Humble Dialog Box"というタイトルの記事で最もよく説明したものです。 4年前にこのような騒動を引き起こしたのは、Model-View-Presenterパターンの背後にある基本的な考えです。パッシブビューと監督コントローラのパターンに分割されました。この質問の記事リンクは、これらのアイデアを活用していますが、テストドリブンな方法ではなく、テスト後のものです。
アイデアは、ビューを除くすべてのドライブをテストすることです。確かに、私たちは良い見通しを立てる必要はありません。確かに、このビューは非常に不条理に単純なので、単体テストのテストはまったく必要ありません。あるいはそうであれば、実際には最後に書かれます。
監視コントローラをテストするには、データが画面にどのように表示されるかを確認するだけです。データがどこにあるのか、フォントが何であるか、どのような色であるか、GUIの大規模な繰り返しを引き起こすその他の美容上の問題を知る必要はありません。むしろ、1つのデータ項目が何らかのテキストフィールドになることはわかっています。もう1つはメニューになり、もう1つはボタンまたはチェックボックスになります。そして、これらのアイテムを正しくレンダリングするためには、Viewが質問する必要があるすべての質問を要求できることを確認します。
たとえば、テキストボックスにデフォルト値が設定されている場合があります。ビューはそれを求めることができるはずです。メニューには、一部の項目がグレー表示されている場合があります。ビューはこの情報を要求できます。ビューが尋ねる質問はすべてプレゼンテーションに関するものであり、ビジネスルールはありません。
同様に、ビューは変更があったときに監督管理者に通知します。コントローラは、あらゆる種類の検証やエラー回復を含めて、データを適切に変更します。その後、Viewはデータの提示方法を尋ねることができます。
これはすべて視覚的な表示から切り離されているため、このすべてはテスト駆動にすることができます。すべてについてはのデータが操作されて表示され、ではなく、のようになります。したがって、大規模に反復する必要はありません。