GUI アプリのフォームの UnitTest

UI 層のオブジェクトの UnitTest は簡単じゃない。
それは否定しない。

ただ、確かに一定の難易度があるにはあるけど、それを何とかする工夫が、かなり昔から研究され、いくつかはパターンとして提唱されて既にかなり広く知れ渡っている。


それにも関わらず、巷の底辺プロジェクトでは、未だに「GUI 層に関しては専用の UI テスト・ツールでも使わない限り、UnitTest は不可能」なんて迷信が未だに根強い。（UI テスト・ツールを使ったテストを、UnitTest の代替物と考えている時点で駄目なんだが･･･）

まあ、４・５年前までは雑誌とかでもそんな感じで言われてたし、未だにその頃の記事が技術系のサイトで閲覧できてたりするから、悪習が減らないのはそういった陳腐化した情報のせいもあるかもしれない。

困った事には、そうした底辺プロジェクトでは何でもかんでも UI 要素のイベント・ハンドラ・コードに書いてフォームを巨大化させるのが常だから、全ソースの半分以上がフォームのコードだったりする。

その上更に、大半の仕様変更がフォームにも影響を与えるものだったりするから、更新回数でいうとフォームのソースが 9割くらいにも達する。そういった、本来は最も UnitTest コードを書くべき部分でサボっておいて、大して変更頻度も高くない部分のカバレッジについて上がったの下がったの言ってるのを現場で見ていると、何とも切なくなってくる。

取り合えず、まず基本はフォームのコードを分割する事。

ユーザ･インタラクションや Windows のメッセージループが必要になる層（以下、View と呼ぶ）と、そうでない層に分ける。View をどこまで薄くするかという技法上の選択肢はあるが、とにかく薄くする。で、残りの部分について、View のインターフェイスに対しておもむろにモック･ツールを適用して、あとは普通に xUnit を使う。

ここまででも UnitTest としては、そこそこの網羅率になる。更にカバレッジを完璧に仕上げたかったら isolation ツール（.net なら TypeMock や Moleなど）を使えば、View についても UnitTest が書けるが、これはオプションと考えて良いと思う。

後で、実際のコード例を挙げてみる。