フロントエンドにおける テスト方針 やじはむ @yajihum 2023/10/25 @CTOA若手エンジニアコミュニティ 勉強会 #4 〜Testing Trophyの概念とBDD〜

@yajihum @yajihum https://yajium.day やじはむ 自己紹介 ↑ロリス @COMPASS Front-end Engineer 社会人2年目

フロントエンドのテスト、 何を意識して書いてますか？ 突然ですが... そもそも、ただ書くのではなく、何かを意識しながら書けていますか？

BDD Testing Trophy 弊社では最近、以下を意識してテストを書いている

E2Eテスト End to Endの略 ヘッドレスブラウザ+UIオートメーションで実施するテストのこと Integration(結合)テスト コンポーネント間の相互作用をテストするもの 単体テストより単位が大きく広くカバーする Unit(単体)テスト コンポーネント単体をテストするもの コーナーケースの検証の向いている 静的解析 TypeScriptやESLintなどによる静的解析 前提として、テストの種類には以下の4つがある

どの範囲のテストにどれくらいのコストをかけるか テストピラミッドの図 参照：https://gihyo.jp/dev/serial/01/savanna-letter/0005 テストピラミッドは、 Unitテストの比率が一番高くな るようにしている フロントエンドのテストにおいて 本当に効果的か？

最適化の答えの一つ Testing Trophyの考え方 Testing Trophyの図 参照：https://testingjavascript.com/ Testing Library の 作 者 で あ る Kent C.Doddsは、 Integrationテスト に最もコストをかけるべきだと 言っている

なぜInteg rationテストか？ Testing Trophyの図 参照：https://testingjavascript.com/ コンポーネントだけで成立する機能は ほとんどない フロントエンドにおいて、単体の Integrationテストが一番 効果とコストのバランスが取れている ソフトウェアが正しく動くことを 保証する効果が薄いのに単体テストを多 く書くことは最適ではない

Testing Trophyのテスト方針とBDD Integrationテストを多く書くことが大切なのはわかったが、 具体的に何をどう書いていけばいいか？ ⭐️実装の詳細をテストしないことが大切

Testing Trophyのテスト方針とBDD 実装の詳細とは？ →簡単に言うと、「ユーザーから見えないもの」のこと 例えば、以下の2つの対比がある ユーザーから見えないもの コンポーネント内で使用している関数 ステートなど ユーザーから見えるもの ボタンや表示されているテキスト UI部分全般

Testing Torphyのテスト方針とBDD なぜ実装の詳細を書いてはいけないのか？ False Negative 壊れるべきでないときに壊れてしまう ユーザーの振る舞いを変えずに実装の詳細だけを変更（リファクタリン グ）するときに、実装の詳細を書いたテストは当然壊れる False Positive 壊れるべきときに壊れない 実装の詳細のテストは粒度が小さいため、コンポーネント間の連携などの 挙動を担保できない テストは通っているのに、アプリ全体の挙動は壊れているなどに繋がる

Testing Torphyのテスト方針とBDD ユーザーから見えるものをテストする つまりBDDをするということ！ BDD：Behavior-Driven Development（振る舞い駆動開発） 「ユーザーがこれをするとこうなる」という粒度（抽象度）でテストを書くこと になるので、ユースケース単位のコンポーネント間の連携テストが書きやすい

まとめ Testing Trophyの概念とは、各テストの効果とコストを 考えた上で、一番効果的なIntegrationテストをたくさん 書こうというもの Testing Trophyの概念に沿ったテストの書き方として、 「実装の詳細を書かない」ことが大切 「実装の詳細を書かない」→「ユーザーから見えるものを テストする」にはBDDをしよう！

ご清聴 ありがとうございました！

参考 【フロントエンド】コンポーネント指向 React / Vue のテスト 方針 テストピラミッド～自動テストの信頼性を中長期的に保つ最適 なバランス～ フロントエンド開発のためのテスト入門 今からでも知っておき たい自動テスト戦略の必須知識