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
kkkw
June 22, 2017
Programming
0
3.9k
テストを遅くしないように気をつけること
kkkw
June 22, 2017
Tweet
Share
More Decks by kkkw
See All by kkkw
GIT中級者への道
kkkw
0
870
マネジメントするときに気をつけていること
kkkw
0
620
社内勉強会 脱!Git初心者
kkkw
0
210
Other Decks in Programming
See All in Programming
Beyond Portability: Live Migration for Evolving WebAssembly Workloads
chikuwait
0
390
20250628_非エンジニアがバイブコーディングしてみた
ponponmikankan
0
350
CursorはMCPを使った方が良いぞ
taigakono
1
170
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
490
deno-redisの紹介とJSRパッケージの運用について (toranoana.deno #21)
uki00a
0
140
アンドパッドの Go 勉強会「 gopher 会」とその内容の紹介
andpad
0
260
A2A プロトコルを試してみる
azukiazusa1
2
1.1k
Enterprise Web App. Development (2): Version Control Tool Training Ver. 5.1
knakagawa
1
120
ruby.wasmで多人数リアルタイム通信ゲームを作ろう
lnit
2
250
AIエージェントはこう育てる - GitHub Copilot Agentとチームの共進化サイクル
koboriakira
0
350
イベントストーミング図からコードへの変換手順 / Procedure for Converting Event Storming Diagrams to Code
nrslib
1
330
[初登壇@jAZUG]アプリ開発者が気になるGoogleCloud/Azure+wasm/wasi
asaringo
0
130
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Visualization
eitanlees
146
16k
Docker and Python
trallard
44
3.4k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Testing 201, or: Great Expectations
jmmastey
42
7.5k
Typedesign – Prime Four
hannesfritz
42
2.7k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
124
52k
The World Runs on Bad Software
bkeepers
PRO
69
11k
The Pragmatic Product Professional
lauravandoore
35
6.7k
KATA
mclloyd
29
14k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
How GitHub (no longer) Works
holman
314
140k
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 に置き換える
ご静聴ありがとうございました