はじめに
今回は「テスト自動化あるある言いたい」への記事投稿をします。
テスト自動化あるあるとして、「単体テストを作り過ぎてしまう」というのがあると思います。
もちろん、作って悪いことはないのですが、以下のような状況なっていることも多くあります。
- カバレッジのためのテストを作り過ぎている
- カバレッジが高い割に、結合テストでバグが多い（本質的なテストができていない）
- 単体テストの作成に時間をかけて、結合テストは一部のケースしか自動化できていない
こうなってしまうのは、自動テストを作る際に「Test Pyramid (テスト・ピラミッド)」の考えが根底にあるのが１つの要因になっていると思います。
そこで今回は、「Test Pyramid」に変わる「Testing Trophy (テスティング・トロフィー」について紹介します。
「Test Pyramid」と「Testing Trophy」
自動テストを作る際に、単体テストや結合テストといった各種テストをどのようなバランスで作成すべきか？ という課題があります。
「Test Pyramid」と「Testing Trophy」はそれぞれ作成すべきテストケースの配分を示す概念です。
Test Pyramidとは？
Test Pyramidの方はその名の通り、作成すべきテストの配分をピラミッド型で表したものです。
画像の通り、Unit Tests (単体テスト) => Integration Tests (結合テスト) => End-to-End Tests (E2Eテスト) の順の分量でテストを作っていきます。
低コストな「Unit Tests」を多数作成し、高コストな「End-to-End Tests」は少量に抑えるべき、という考えです。
Testing Trophyとは？
こちらも名前の通り、作成すべきテストの配分をトロフィー型で表したものです。
フロントエンド向けに提唱されたものですが、バックエンド開発でも共通して適用できます。
from: https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications
-
Static Testing
型チェックやLintツール、静的解析ツールを使って少ないコストで品質を担保できるので必ず入れる。トロフィーの基盤という位置付け -
Unit Tests
作成し過ぎないようにする。カバレッジでいうと100%を目指すのではなく、70%程度に留めておく -
Integration Tests
最も重視する -
End-to-End Testsを絞るべき理由
システム全体のテストは高コストであるため、クリティカルなパスだけに限定する
Testing Trophyの特徴とユースケース
Test PyramidはUnit Testsを重視しますが、Testing TrophyではIntegration Testsを最も重視します。
もちろん「Unit Tests を書かなくて良い」というわけではなく、「書き過ぎないように」ということです。(カバレッジでいうと100%を目指すのではなく、70%程度に留めておく)
※ 共通部品などはきちんとテストするとして、単体であまり意味をなさない部品に労力をかけ過ぎない
また、昨今では導入が当たり前となった静的解析についても言及しています。
Integration Testsを重視する大きな理由は、部品単体でうまく動いていても、ソフトウェア全体が正しく動くことを確認できないためです。
提唱者のブログで紹介されている以下のPostがその理由を巧く表しています。
どのあたりから始めるか
「Testing Trophyの考えを取り入れてみようかな」と思っていただけたら、以下のあたりから取り組んでみてください。
- 静的解析ソフトを入れていなければ入れる
- Integration Testのツールやライブラリを使ってテストを作成する（例：Playwright、Cypressなど）
- 上記をCIに組み込む
本記事では紹介レベルに留めております
深い部分や、具体的な実践については別の詳しい記事をご参照いただけると幸いです
まとめ
Testing Trophyは、コンポーネント化されたフロントエンド開発や、モジュール化の進んだバックエンド開発にも適したテストの考え方だと思います。
興味を持っていただけたら、テスト計画時の参考にしていただけたら幸いです。
参考