Androidのテストサイズとテストスコープ

※今後こちらの記事の引用が続く
https://logmi.jp/main/technology/330972

データベースにアクセスする。「ユニットテストとは何ですか？　あなたにとってのユニットテストとは何かとか、あなたのチームにとってのユニットテストとは何か」。ユニットテストであってもデータベースにアクセスしてもいいよって思う人、手を挙げてください。そういうチームもあると思います。例えばRailsのテストとか、そうですよね。
ネットワークにアクセスするのはユニットテストですか？　Yes、No。はい。Yesでもいいです。ちなみにこれ、答えに正解はないですよ。何をやろうとしているかというと、「ブレブレです」ということをやろうとしています。
ファイルにアクセスするユニットテストはOKですか？　これはOKな人、多いですよね。半分ぐらい挙がりますね。現在時刻はどうでしょう。currentTimeMillisみたいなの、ありますよね。
もう最後。最後はちょっとだけ特殊で、なんかこの真ん中の、この緑のひし形がテストコードだと思ってください。テストコードでテストしようとしている対象がいます。テストしようとしている対象が依存しているやつがいます。モジュールAがあって、モジュールAはモジュールBとCに依存しています。よく、このモジュールBとCを本物をそのまま使うか、それともテストダブルという偽物、モックとかスタブと言われる偽物に置き換えるか。
これ、けっこうスタイルが分かれるし、チームによって本物使うのはユニットテストじゃない、偽物に置き換えるのがユニットテストだよと定義付けするチームも、流派もあったりします。みなさんはどっちだと思いますか？
ちなみに、「依存先のモジュールに本物を使うのはユニットテストだと思う」。Yes、No。これも割れますね、半分ぐらい。というわけなんですね。

ユニットテスト、インテグレーションテスト、E2Eテストなどのテストスコープは結構人によって定義が曖昧。そこの認識を合わせるのは大事。けれど「このパターンはユニットテスト？」と聞くと、本当に5:5になるぐらいバラバラ。

「テストサイズ」はテストスコープとは別軸の考え方。
テストスコープより定義が分かりやすい。

テストにはサイズっていうやつがあります。Small、Medium、Large。小、中、大というわけですね。Small Testの定義は何か？　Small Testの定義は、テストの実行が1つのプロセスに収まっているものをSmall Testというようにしようと。
1つのプロセスには収まっていないけど、1つのマシンに収まっているやつをMedium Testと呼ぼうと。1つのマシンに収まっていないのをLarge Testと呼ぼうという、3つのサイズに分けよう。これは、ものすごく明確です。プロセスに閉じていればSmall、閉じてないけど1つのマシンに閉じていればMedium、閉じていなければLargeというわけですね。

テストサイズSmallはネットワークもファイルもデータベースもアクセスしない。
Mediumは外部システムは推奨しない。
Largeはなんでもあり。

テストサイズとテストスコープをマトリクスにする。
GoogleのAndroidチームがやっているらしい。
コスパが良い領域がある

• 単一プロセスに収まっているインテグレーションテスト

逆におすすめしない領域

• Largeだけどユニット
• 実システムを使って、外部のネットワークアクセスもある状態で、でもユニット相当のもの
  • エンドツーエンドテストのツールを使って画面のバリデーションロジックとかを網羅的にテストしている
    ンロジックとかを網羅的にテストしているみたいなのを、すごくよく見かけるんですよね。

なぜおすすめしないか

• Largeだから遅くて不安定

従来のテストスコープによるピラミッドは、そもそも分類の認識ズレがある。

• どこからどこまでがインテグレーションテスト？

テストサイズでピラミッドを定義する。