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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
kkkw
June 22, 2017
Programming
4k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
テストを遅くしないように気をつけること
kkkw
June 22, 2017
More Decks by kkkw
See All by kkkw
GIT中級者への道
kkkw
0
920
マネジメントするときに気をつけていること
kkkw
0
670
社内勉強会 脱!Git初心者
kkkw
0
230
Other Decks in Programming
See All in Programming
Make SRE Operations Easier with Azure SRE Agent
kkamegawa
0
6k
Developing with AI Agents — Codex, Claude Code & Cowork Practical Guide
x5gtrn
PRO
0
1.3k
並列実装の現場、2ヶ月間実務でAIを使い倒したAIもPCも私も限界が近い
ming_ayami
0
130
AIだと陥りがちなJakarta EE最新技術への移行時の落とし穴と解決策
tnagao7
0
110
RTSPクライアントを自作してみた話
simotin13
0
600
キャリア迷子上等 ─ "ない道"は自分で作ればいい
16bitidol
3
2.1k
例外の正しい扱い方 そのエラー try-catchして大丈夫?
jinwatanabe
0
230
Oxlintのカスタムルールの現況
syumai
6
1.1k
AIで効率化できた業務・日常
ochtum
0
130
「エンジニアインターン、どうやって取った?」準備のリアルを語るLT会 Progate BAR
akiomatic
0
130
気づいたらRubyで100作品 ー クリエイティブコーディングが生活の一部になるまで / 100 Ruby Sketches Later: How Creative Coding Became Part of My Life
chobishiba
3
570
Lessons from Spec-Driven Development
simas
PRO
0
190
Featured
See All Featured
Utilizing Notion as your number one productivity tool
mfonobong
4
320
A Tale of Four Properties
chriscoyier
163
24k
Crafting Experiences
bethany
1
180
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
1
3.6k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
How to Ace a Technical Interview
jacobian
281
24k
How to make the Groovebox
asonas
2
2.2k
The Curse of the Amulet
leimatthew05
1
13k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.9k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
940
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.2k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1.2k
Transcript
テストを 遅くしないように 気をつけること MatchingAgent x Makuake 合同勉強会 2017/06/22 ( 木)
@kkkw
お前誰よ @kkkw フリーランス 2017 年2 月~ Makuake にjoin サーバーサイド中心に上から下まで
Agenda テストが遅いと何が困るのか Makuake でやったテストの高速化 テストコードのリファクタ例
テストが遅いと何が困るのか CI が詰まる PR 発行( テスト走る) →マージ→デプロイの流れ 緊急リリースだと致命的 品質が落ちる テストを書く、実行するモチベーションが落ちる
開発手法の選択肢が減ることもある
Makuake でやったテストの高速化
やったこと 1. MySQL のチューニング 2. テストコードのリファクタ
Jenkins のjob 実行時間
MySQL のチューニング 環境依存のお話なので今日は割愛
テストコードのリファクタ 基本的にはプロダクションコードと 同じことに気をつける 重い処理をやらない データベースのアクセス 外部へのhttp アクセス ディスクI/O テストそのものが必要かどうか考える
いくつか紹介 なるべくDB へアクセスしない方法を紹介 php でのサンプル スライドの都合上PSR とかは無視 確認してないのでエラーとかあるかも
そのFind 本当に必要? 本当にDB のsetUP が必要かどうか考える 安易に、 nd しない
テストしたいコード Class User { public function get_image_path() { return 'img/user/'.$this->id.'/main.jpg';
} }
よくあるテスト nd で取ってきてる setUp でDB の初期化が必要になる $user = User::find(1); assertSame('img/user/1/main.jpg'
, $user->get_image_path());
こっちのが速い DB から検索するのではなく 引数与えてオブジェクト作る $user = User::forge(['id'=>1]); assertSame('img/user/1/main.jpg' , $user->get_image_path());
フレームワークに喧嘩を売らない 提供されている機能をテストする必要はない 必要があるのは、ちゃんと設定 or 使えているか 例えば論理削除のテスト
users テーブル id name deleted_at 1 山田太郎 null 2 山田花子
2017-06-22 12:00:00
よくあるテスト $actual = User::find(1); assertNotEmpty($actual); $actual = User::find(2); assertEmpty($actual);
こっちのが速い 例えば、論理削除のクラスを継承していることを 確認するテストにする assertSame('SoftDelete', class_parents(User::class));
Mock を使って遅い処理を避ける 時間のかかる処理を毎回にコールする必要はない。 ただし、Mock は使うべきときだけ使うようにする。
テストしたいコード AB テスト用に取ってきたユーザーを A グループとB グループに分ける class ServiceUser { public
function get_ab_groups(){ $users = User::get_something(); // 時間 SQL User 配列 返 $a = $b = []; foreach($users as $user){ if($user->id % 2 === 0) $a[] = $user; else $b[] = $user; } return [ 'a' => $a, 'b' => $b, ]; } }
こうすると早くはできる $users = array_map(function($i){ return User::forge(['id'=> $i]); }, range(1,2)); $mock
= Mockery::mock('alias:' . User::class); $mock->shouldReceive('get_something')->andReturn($users); $actual = (new ServiceUser())->get_ab_groups(); assertSomething($actual);
TestCase クラスは、2 つに分ける 大抵のテスティングフレームワークは、 TestCase ク ラスのsetUp メソッドでデータの初期化を行うので、 TestCase クラスそのものを分けるようにしておく。
ModelUserTest ModelUserNoDbTest ※ディスクの遅い環境は増やしすぎ注意
3 つだとさらによい ModelUserTest データの更新が発生するため毎回初期化する ModelUserReadTest 読み取りのみ。最初だけ初期化する 初期化をsetUp ではなく、setUpBeforeClass 的な とこでやる
ModelUserNoDbTest データベースを全く使わない
まとめ 遅いテストは悪 テストを走らせる環境のチューニングはする 遅い処理は書かないでテストできないか検討する 最悪Mock に置き換える
ご静聴ありがとうございました