Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
良いテストとは何か:持続可能で保守性の高いテストを書く
Search
picopico
October 09, 2023
Programming
16
5.5k
良いテストとは何か:持続可能で保守性の高いテストを書く
PHPカンファレンス2023の登壇資料です。
https://fortee.jp/phpcon-2023/proposal/10143d00-ca44-4db1-aeb6-b618c423b646
picopico
October 09, 2023
Tweet
Share
More Decks by picopico
See All by picopico
PHP 8.4がリリース! あなたはもうアップデートしましたか?
picopico
0
260
PHPとFluentdで実現するリアルタイムログ分析
picopico
2
360
2023 State of DevOps Report」簡易ピックアップ
picopico
0
120
トーク力は一生役に立つよ
picopico
1
630
伝え方で変わるLTの世界
picopico
3
1.3k
エラー処理関数を完全に理解する
picopico
0
130
一日30回リリースを可能にするpixiv開発
picopico
6
2.9k
Other Decks in Programming
See All in Programming
dbt民主化とLLMによる開発ブースト ~ AI Readyな分析サイクルを目指して ~
yoshyum
3
1.1k
Rubyでやりたい駆動開発 / Ruby driven development
chobishiba
1
750
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
260
The Niche of CDK Grant オブジェクトって何者?/the-niche-of-cdk-what-isgrant-object
hassaku63
1
490
Git Sync を超える!OSS で実現する CDK Pull 型デプロイ / Deploying CDK with PipeCD in Pull-style
tkikuc
3
230
Agentic Coding: The Future of Software Development with Agents
mitsuhiko
0
120
Flutterで備える!Accessibility Nutrition Labels完全ガイド
yuukiw00w
0
170
High-Level Programming Languages in AI Era -Human Thought and Mind-
hayat01sh1da
PRO
0
830
Startups on Rails in Past, Present and Future–Irina Nazarova, RailsConf 2025
irinanazarova
0
180
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
890
#QiitaBash MCPのセキュリティ
ryosukedtomita
1
1.4k
PostgreSQLのRow Level SecurityをPHPのORMで扱う Eloquent vs Doctrine #phpcon #track2
77web
2
560
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
The World Runs on Bad Software
bkeepers
PRO
69
11k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.4k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
GitHub's CSS Performance
jonrohan
1031
460k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Unsuck your backbone
ammeep
671
58k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
830
Transcript
良いテストとは何か: 持続可能で保守性の⾼いテストを書く @picopico_dev
テスト、書いていますか?
「良い」テスト、書いていますか?
4 会社 ピクシブ株式会社 経歴 2023年4⽉ 新卒⼊社 業務 Web API設計/PHP .
移⾏ picopico @picopico_dev
⽬次 1. なぜ良いテストが必要なのか 2. 良いテストの指標 3. 良いテストの書き⽅
⽬次 1. なぜ良いテストが必要なのか 2. 良いテストの指標 3. 良いテストの書き⽅
前提:テストは書くべき
テストを書く恩恵 • 機能変更‧リファクタリングしやすい • 素早いフィードバックによる⾼速な開発 • 優れたドキュメンテーション • etc…
テストの質が悪いと‧‧‧? • テストを修正しづらい • すぐテストが壊れる • テストの実⾏が終わらない • たまに原因不明で落ちる •
etc…
コードは資産ではなく負債 コードが多いほど、保守‧運⽤コストがかかる =書かれたテストはゼロコストではない
⽬次 1. なぜ良いテストが必要なのか 2. 良いテストの指標 3. 良いテストの書き⽅
「良い単体テストを構成する4本の柱」 • リグレッションへのセーフティネット • リファクタリング耐性 • 迅速なフィードバック • 保守のしやすさ 「単体テストの考え⽅/使い⽅」p.96
「単体テストを早期に⾏う利点」 • 瞬間的な満⾜感 • モジュール性‧再利⽤性の向上 • リファクタリング‧セーフネット • ドキュメンテーション 「The
Advantages of Unit Testing Early」- Google Testing Blog (https://testing.googleblog.com/2009/07/by-shyam-seshadri-nowadays-when-i-talk.html)
良いテスト =価値の⾼いテスト シンプルに‧‧‧
価値=機能÷コスト
価値=機能÷コスト
コードが正しいことを保証すること 半分間違い
テストの機能 フィードバックループの構築 ドキュメンテーション +
テストの機能 フィードバックループの構築 ドキュメンテーション +
フィードバックループの構築 コードの変更 テスト リリース
シフトレフト
低い⽋陥コストでバグを修正できる →素早いリリースが可能になる →持続可能で保守性の⾼いプロダクトに
テストの機能 フィードバックループの構築 ドキュメンテーション +
ドキュメンテーション • 信頼度が⾼い • Howをコードで⽰している
信頼度が⾼い システム ⽂書 コメント テスト
価値=機能÷コスト
テストのコスト 実装コスト 保守コスト 運⽤コスト + +
テストのコスト 実装コスト 保守コスト 運⽤コスト + +
実装コスト • フレームワークの導⼊ • テストの作成 • CIへの組み込み • 学習
実装コスト テストコードはプロダクションコードより多い
テストのコスト 実装コスト 保守コスト 運⽤コスト + +
保守コスト • フレームワークのアップデート • コード変更時のテストの修正
テストのコスト 実装コスト 保守コスト 運⽤コスト + +
運⽤コスト • テストの実⾏ • CIサーバーの運⽤
価値=機能÷コスト
フィードバックループの構築 実装コスト ドキュメンテーション 運⽤コスト 保守コスト 価値 = ÷
⽬次 1. なぜ良いテストが必要なのか 2. 良いテストの指標 3. 良いテストの書き⽅
良いテストを書くには • 正確なフィードバック • ⾼速なフィードバック • 理解しやすいテスト • テストする価値の⾼いシステムをテストする
良いテストを書くには • 正確なフィードバック • ⾼速なフィードバック • 理解しやすいテスト • テストする価値の⾼いシステムをテストする
正確なフィードバック • 機能が正しく実装されているとき →テストが通る • 機能が正しく実装されていないとき →テストが落ちる
正確なフィードバック 機能が正しくない 機能が正しい テストが通らない 真陰性 偽陽性 テストが通る 偽陰性 真陽性
正確なフィードバック コードの変更 テスト リリース 偽陽性
ホワイトボックステスト • ソフトウェアが内部的に⾏っていることを検証する • Howに依存するため、リファクタリング耐性が低い
ブラックボックステスト • ソフトウェアの振る舞いのみを検証する • Whatに依存するため、リファクタリング耐性が⾼い
正確なフィードバック コードの変更 テスト リリース 偽陰性
偽陰性を減らす • ロジックが正しく動くか • コンポーネントが結合された状態で動くか
テストピラミッド E2E Integration Unit
良いテストを書くには • 正確なフィードバック • ⾼速なフィードバック • 理解しやすいテスト • テストする価値の⾼いシステムをテストする
⾼速なフィードバック コードの変更 テスト リリース できるだけ速く
テストピラミッド E2E Integration Unit
テストサイズ 機能 Small Medium Large ネットワークアクセス No localhost only Yes
データベース No Yes Yes ファイルシステムアクセス No Yes Yes 外部システムの利用 No Discouraged Yes マルチスレッド No Yes Yes スリープ文 No Yes Yes システムプロパティ No Yes Yes 時間制限 (秒) 60 300 900+ 「Test Sizes」- Google Testing Blog (https://testing.googleblog.com/2010/12/test-sizes.html)
良いテストを書くには • 正確なフィードバック • ⾼速なフィードバック • 理解しやすいテスト • テストする価値の⾼いシステムをテストする
理解しやすいテスト • AAAパターン ◦ Arrange - 準備 ◦ Act -
実⾏ ◦ Assert - 確認 • テストケースと振る舞いを対応させる • ⼀度に⼀つの振る舞いを検証する
良いテストを書くには • 正確なフィードバック • ⾼速なフィードバック • 理解しやすいテスト • テストする価値の⾼いシステムをテストする
テストする価値の⾼いシステム • コアドメインに近い • ロジックが複雑である
テストする価値の低いシステム • 単発のスクリプト • 書き直した⽅が早い • ロジックをほぼ持たない
テスタビリティについて
フィードバックループの構築 実装コスト ドキュメンテーション 運⽤コスト 保守コスト 価値 = ÷
実装コスト =テスト対象システムで決まる
Class A Class C Class B Class D
DIとテストダブル • 依存をコンストラクタで注⼊する • テスト時には依存クラスをテストダブルに置き換える
おわり