こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
3/3(金)に行われたエンジニア文化祭の講演を見返していこうという会です。
今回は、t_wadaさんの講演を見返していきました。
会の様子
学習用テスト
まず、学んだことを自動テストとして書いていく学習用テストの話がありました。
あの時調べたことが今でも正しいのか？というのを担保することができるため、他の人が書いたコードやふるまいが不明なテストに対して活用することが多いということです。
学習目的で使用するテストのため、不要になる場合も多く、何かしらタグで管理しておくと便利だということでした。*1
また、驚きをテストすることにも有効であるため、例えばJSでコンストラクタをもう一度呼ぶことで破壊的変更を起こして、それをテストに落としておくことも有効だということでした。
偽陽性と偽陰性
自動テストの信頼性の高さ*2は企業の業績にも直結しているということで、自動テストの誤検知の話として、偽陽性*3と偽陰性*4の話がありました。
偽陽性と偽陰性は、プロダクトコードとテスト結果の関係性から、
- テスト結果が成功×プロダクトコードが正しい...期待値通り
- テスト結果が成功×プロダクトコードが誤っている...偽陰性
- テスト結果が失敗×プロダクトコードが正しい...偽陽性
- テスト結果が失敗×プロダクトコードが誤っている...期待値通り
と整理できるということです。
テストサイズ
テストスコープの問題は、DBのテスト/NWアクセステスト/ファイルアクセステストをどこまでやるのか？という話があったり、そもそもUnit testのUnitにも古典派とロンドン学派があったりと、定義や考え方にかなりばらつきがあるため、テストのスコープよりもテストのサイズで考えようという話が続いて紹介されました。*5
そのため、テストサイズとテストスコープもパターンごとに整理するのが有効ということで、以下の内容が紹介されていきました。
- Unit × Small Size...大いに推奨
- Integration × Small Size...書けるならコスパ良い
- E2E × Small Size...実質不可能
- Unit × Midium Size...避けるべきだが仕方がないときもある
- Integration × Midium Size...普通
- E2E × Midium Size...小さいシステムなら可能
- Unit × Large Size...最悪(ただしよく見かける)
- Integration × Large Size...できれば避けたい
- E2E × Large Size...普通(CUJにしぼりたい)
テストダブル
続いて、テストダブルの話がありました。
テストダブルもテストスコープと同じように用語の混乱があったそうですが、X Unit test patternsで統一されたということで、今回はこの定義に沿って話が進んでいきました。
テストダブルはテストしにくいものがテスト可能になったりテストの速度と決定性を向上させる一方で、テストが脆くなったりテストの偽陰性を招くリスクがあるため、注意が必要だということでした。
テストピラミッド
最後に、自動テストの信頼性を中長期的に保つためのテストピラミッドの話がありました。
テストピラミッドは、コストが高い速度が遅いE2Eテスト < コストも速度も普通なIntegration test < コストが安く速度が速いUnit testとテスト量を整理しようというアイデアですが、これは個々人がUnit testをどう考えているかによって解釈の混乱が起きがちなので、ここまで説明してきた内容を活用しようというアイデアの紹介がありました。
その他(t_wadaさんの失職危機)
単体テストの考え方/使い方、ChatGPTはt_wadaさん的に失職の危機を感じるほど正確だという余談が紹介されていきました。
会全体を通した感想
t_wadaさんがWEB+DB PRESSでしてきたこれまでの連載が見事にまとまっていて安定の品質になっており、聞きやすかったです。
個人的に、テストピラミッドの話をするために連載を積み上げていたことが知れたのは、特に良かったです。
