GUIのTDDは難しい

理由はものすごく簡単で、自動テストだけで本当の意味での正しさを確認しにくいから。
単純にINPUTとOUTPUTが数字や文字列といったデータで確認できる場合は、プログラムとして評価を書きやすいのだが、GUIのレイアウトの部分などは、視覚的に見ないと普通は判断できない。
これがソースコード＝レイアウトが判断できるもの、であれば成立するが、現状はそういう都合のいいコードは存在しないと思います。

解決手段

目をテストの代わりにする

当たり前ながら、これが一番簡単。
要は、TDDというのは自動テストのコードによって常に確認しながら、プロダクトコードを書いているわけだから、コンピューターの代わりに常に目が監視してあげるしか基本的には存在しない。

ただし、それだけではCIなど、繰り返しテストをするという観点で足りない部分があると思う。
なので、RED > GREEN の部分では自動テストを諦めて、リファクタリングの一部として結果を残す意味で、自分が目で行ったテストを部分的に自動テストに置き換える。
これで、ほとんどは代替できると思う。

レイアウトとロジックを分離する

プログラムの品質を上げるうえではこれが一番重要かと思う。
テストを何度もしなくてはいけないような部分、網羅的に様々なパターンを試したい部分というのは、レイアウトに関わることはあれど、それ以上にロジック自身のテストができてて初めてGUIは成立する。

RailsやDjangoなどのフレームワークは、html等の中にロジックを組み込むことができるが、このロジック部分をGUI絡みのソースと切り離し最小化することで、TDDがやりやすい自動テストの領域に引き込むことが可能だ。
それは結果として、ControllerとViewの分離するという設計の改善にも繋がる思想だと思う。

各条件のGUIのスクリーンショットを取るようにする

もともとSelenium等に機能があるので、それを使う。
結局目で確認するのだが、デグレード確認にはかなり有効な手段となる。
自分が業務で行ったときは、対象の言語のライブラリを使ってPPTに張り付けて、タイトルまで載せるようにした。それができれば、それ自身をステークホルダーに渡して「全体的にこう変わりました！」という提出の仕方も可能になる。
重たかったり、ファイルが出来上がって邪魔になるので、特定の条件でのみ実行されるように工夫したほうが使いやすいと思う。

全部をTDDでやろうとしない

身も蓋もないが、すべてにおいて、QCDの中のトレードオフ。時間がかかりすぎたら意味がないので、中長期的に見て効果があるものだけを試すべき。
だからと言って最初から投げ出すのも違うと思うし、振り返りのたびに様々な取り組みをやってみて、効果があるものを探っていくことこそが重要だと思います。

まとめ

書いたのはいいけど、すごく当たり前のことしか書いてないので、参考にならないかもしれませんが、よく諦めるか、無理やり感を感じるときがあるので、投稿してみました。
ご意見ありましたら、コメントください。