#Conference [[📒開発生産性Conference 2024]] [[👤和田 卓人(t_wada)]]さんのセッション [開発生産性の観点から考える自動テスト（2024/06版） / Automated Test Knowledge from Savanna 202406 Findy dev-prod-con edition - Speaker Deck](https://speakerdeck.com/twada/automated-test-knowledge-from-savanna-202406-findy-dev-prod-con-edition) ## MEMO ### なぜ[[🗃️自動テスト]]を書くのだろうか？ - アンチパターン: コスト削減 - 変更容易性の高い[[🗃️ソフトウェア]]による[[🗃️アジリティ]]の獲得が大切 - [[🗃️自動テスト]]はアジリティを獲得するため - 作ったものを変えていくためにテストを書く - [[🗃️自動テスト]]の目的 - 信頼性の高い実行結果に短い時間で到達する状態を保つことで、開発者に根拠ある自信をあたえ、[[🗃️ソフトウェア]]の - テスト自動化と業績の因果関係 - リリースが問題ないとチームが確信できている状態 - 偽陽性 -> 続くとテストを信頼できなくなる - 脆いテスト(fragile test) - 触っただけですぐ壊れるテスト - [[🗃️flaky test]] - 信頼不能性が1%に接近するとテストは価値を失う - 「Googleのソフトウェアエンジニアリング」 - 偽陰性 - 空振り - カバレッジ不足 - 書くべきテストが書かれていない - 自作自演 - テストになっていそうでなっていない - [[🗃️自動テスト]]実行結果の出力と狙い - 信号機としての機能 - [[🗃️自動テスト]]の失敗には2種類 - Execution Error: - Assertion Failure - テストサイズでテストを分類する - small - Medium - Large - サイズでテストを定義するとブレが少なくなる - Largeテストは[[🗃️flaky test]]なので、[[🗃️継続的インテグレーション]]ビルドに含めず定期で実行することもある ### どうやってテストサイズを小さくするのか？ - アイスクリームコーンはアンチパターン - [[🗃️E2Eテスト]]を重視してしまう背景 - [[🗃️E2Eテスト]]の過剰投資はやめたほうがいい - コストがかかる & flakyだから - 大切なのは、リリースできるという自信とデプロイのサイクルを速く回すこと - Large -> Medium - テストダブル - [[🗃️スタブ]]、[[🗃️モック]]のこと - テストダブルの利点 - テストしにくいものをテスト可能にする - テストの速度と決定性を向上させる - **テストサイズをさげる** - テストダブルの注意点 - テストがもろくなる -> 偽陽性を招く - 自作自演テストのリスクがある -> 偽陰性を招く - テストタブルを使ってもテストサイズが小さくならないのであれば、使う意味はない - Medium -> Small - 「テストでは品質はあがらない。テストはあくまで品質をあげるきっかけ 」 - 良いテストを構成する4ほんの柱 - regressionに対する保護 - [[🗃️自動テスト]]の最大の効果は、「根拠ある自信」 - 短い時間で、壊れている/壊れていないを検査すること