「単体テスト（画面単位のテスト）がクソらしいので思ったことを書いてみる - うさぎ組」という記事を読んで考えたこと。割と雑に書く。画面単位の単体テストに関する個人的な考えたかたの整理的なもの。
画面単位の単体テストの是非
まず用語の定義から。「単体テスト」といっても人それぞれだけれども、自分の中では次のような定義で落ち着いている。
テスト可能な最小単位のコンポーネント毎に、ホワイトボックス観点でのテストを実施する。必要に応じてスタブ・ドライバ等を作成し、テスト対象コンポーネントが意図した挙動をすることを確認する。
除去を意図する主要な品質リスクは「コーディングミス」「上流工程成果物の落とし込み漏れ」である。
単体テストフレームワーク(xUnit)に関すること - 勘と経験と読経
- 粒度は「テスト可能な最小単位」という定義にして、割と柔軟に決めている。ここをクラス単位とか固定して規定しちゃうのは事故のもとだと思ってる。
- テストの区分とテストの目的を紐付けるのが重要だと思っている。
で、良し悪しは別として、割と自分は画面単位の単体テストも実施する派だ。
- 基本的に、モックなどを使ってテストするイメージ。出来る限り他のコンポーネントと分離して、画面だけをテストしたい。というわけで、単機能テストとしてではなく、純粋に画面(デザイン＋動き)だけを相手にしたい。
- あまり自動化にこだわっていない。というか自動化できない部分を画面の単体テストとして実施するイメージ。ひょっとしたら最近は良いソリューションがあるのかもしれないけれど、わりと人力で手でやるテストを選択してる。
- 「どうせ後続のテストでも確認するんだから、省略してもいいんじゃないの？」という悪魔の囁きはあるけれど、屈しない。
- もちろんコストの問題はあるけれど、逆にスキップすることでコストが増える可能性もあるわけで、チャレンジするポイントではないと思ってる。
- デザインが崩れているとか、ラベルが間違っているとか、誤植があるとか低レベルのバグは早くにとってしまいたい。後続工程ではもっと悩ましいバグと向かい合いたい。
