モチベーション
テストを実施する際に、UT(単体テスト）、IT(結合テスト)などそれぞれ工程はあるが、
具体的にどんなテストを書くかそれぞれの認識が違うため、すり合わせが大変。
googleで提唱されている、small、middle、largeテストでテスト分類をして認識齟齬を無くしたい
https://testing.googleblog.com/2010/12/test-sizes.html
テストサイズとは？
テストサイズとは、リソースの量や実行場所、実行時間などによって分類する方法。
以下のような分類があります。
small
モジュール単位(単一のソースファイル)に対してテストを行うもの別なモジュールとの連携はモックを利用する。
middle
単一のマシンに閉じた環境であれば外部リソースの利用を許容するテストです。
データベースは、dockerで立ててテストデータは、テスト担当者が作る。
ファイル転送など、別のPCへアクセスするものはモックを利用する。
クラウドへのアクセスも、ローカルPC上でテストできればテスト対象となるが、クラウドを直接使うようなテストは対象外とする。
large
自動テストからリモートマシンへのネットワークアクセスなども許容するテストです。
モックを使わず、全て本物を使用してテストを行う。
テストのロボット（playwrightなど）を使って実施する。
どこを重点的にやるか
テストレベルにおいて理想的な比率を示したものをよくテストピラミッドと表現します。
上に行くほどテストのケース数が少ない方が、テスト効率が良いという考えです。
実際、E2Eテストが一番重いので、量が多いとなかなか自動テストが終わらなくマージできないといったプロジェクトもありました。
このテストピラミッドに対応したテストを計画することが基本と考えています。
どこを重点的にやるか（アレンジ）
最近のプログラムではライブラリが充実しており、複雑なプログラムを書く機会が少ないと感じています。
個人的にはmiddleテストを重点的にやった方が、不具合が取れると考えています。
なので、テストピラミッドではなく、テストトロフィーを推奨します。
これにより、機能の仕様確認に近いテストが多く実施され品質の保証がしやすくなると考えています。
*saticはlinterなどの静的解析を指す
各工程でのテスト
UT、ITでそれぞれどんなテストを実施するかについてですが、
UTは、smallテストと、middleテストを実施するのが良いと考えています。
理由としては、この工程ではできるだけ不具合を取りたいのでmiddleテストまで含めたい考えです。
ITでは、largeテストを実施を考えています。
シナリオを作ってテストするのがlargeテストですが、実施コストが高いので王道パターンを自動テストに組み込み実施するのが良いと考えています。