Small/Medium/Large/Enormousと4段階にテストレベルを区分して、それぞれで実施するテストの粒度や目的をつらつら書いています。 テストレベルは、どいう目的で、何を実施して、どんな不具合を検出するか、を定義した区間です。(ざっくり)
ただ、ここでは目的なんかもちゃんと定義しているわけではなく、開発者が行うテストとするとこのくらいの分け方かな、くらいの温度感です。 (ちゃんとすると、アジャイルテストの4象限とかな区分もありますが、そこまでは到底整理してないです...)
AndroidではSmallTest/MedisuTest/LargeTestと3つのアノテーションがあらかじめ用意されていますが、Enormous以外はそれに対比させて考えていきます。EnormousはLarge以上のテスト環境で行うもの、という位置付けです。
区間を分ける際のざっくりとした基準として気にしている点です。
- 実施時間
- 周辺環境の規模
- localやmockで済めば規模は小さく、実システムに近寄るほどテスト環境の規模は大きくなります
細かくいうと、実装内容を知っているか？とか云々ありますが、ここではそこまでは言及しません。
- 主に、instrumentsに依存しないロジックのテスト(理想)
- 広く、unit testと呼ばれる領域
- Viewが絡まない、model層のテストなんかは基本これ
- model層の、contextなどのAndroid固有の要素が絡まない内容の確認を行うことを理想像としたい
- 最終的に、ここはJVM上で実施できう感じの切り分けできると嬉しいですね
- ControllerやViweが絡むところは気にしない
- instrumentsに依存する(contextが必要になるような)ロジックのテスト
- 広く、integrationと呼ばれる領域
- modelとAndroid固有の実装の依存関係に注目したところをテストしたい
- 特定の条件に合致した時の描画が正しいかどうか、を確認する
- ここでいう正しいとは、例えば"xxx"と表示されたボタンが存在する、といった要素の存在確認程度
- Viewの描画までも許容されるが、clickなどの操作を複数またぐことはしない
- 例えば、Viewを表示するタイミングでローカルのデータがxxxなので、yyyのダイアログが出るはずだ、という限りのテスト
- xxxをクリックして、yyyが描画されたらzzzをして、さらにrrrする！といった長いシナリオはここでは書かない
- サーバ環境は、理想はMockサーバやAssetsを想定
- 不安定になるので、できれば実ネットワークを介さない形にしたい...(理想)
- 複数のviewをまたいだり、なんらかのactionを実施した上で変化するところ(主にView)に注目したテスト
- Viewに対して文字を入力したり、何かをクリックして他Activityをintentで起動、正しく起動されるかといったものを確認する
- Espressoでいう、clickとかをフルで使いまくるテスト
- スクリーンショットを撮っての確認などのGUI Testも実施する
- Appiumなんかでも同様のことはできるが、多分理想はEsspresso
- Mockサーバなど使って閉じた環境を作った上で実施する環境が良い(理想)
- このMockサーバはいわゆるStagingサーバのような環境でも十分そうな気はしています
- 複数のパッケージをまたいだ、例えばSingleSignOnなどは考慮しない
- あくまでも、1つのパッケージに限定し、さらにはアプリのViewを満遍なく確認することを目的としたテスト
- Appiumなどを使い、完全にリリース物をテストする
- ブラウザでいうE2Eとか、システムテストとかよく言われる領域
- シナリオと実装を切り離した上で、ユーザの操作ベースでテストを記述する(のが理想)
- スクリーンショットを撮っての確認などのGUI Testも実施する
- 複数パッケージをまたいだテストを行う
- サーバなど、基本的にMockは使わない
- いわゆるオペレータ（エクセルなどで管理されたテストを実施する人）が行うテスト
- ほかにも諸々...
流れとしては、
Small < Medium < Large < Enormous
と時間がかかるけれど、実際のユーザストーリやシナリオに即したテストになっていくという方向感覚です。 また、テストの量もそれに習ってSmallが一番多く、Enormousが一番小さいピラミッドを描くことが理想だと思ってます。
ただ、現状はこんなに綺麗に行かなくて、多分Small/Mediumは多く、その次にEnourmousにいくようなプロジェクトが多いかと思います。