$30 off During Our Annual Pro Sale. View Details »

フロントエンドにおける テスト方針〜Testing Trophyの概念とBDD〜

フロントエンドにおける テスト方針〜Testing Trophyの概念とBDD〜

2023/10/25 CTOA若手エンジニアコミュニティ 勉強会 #4

やじはむ

October 25, 2023
Tweet

More Decks by やじはむ

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  14. ご清聴
    ありがとうございました!

    View Slide

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

    View Slide