Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
テストを遅くしないように気をつけること
Search
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
930
マネジメントするときに気をつけていること
kkkw
0
680
社内勉強会 脱!Git初心者
kkkw
0
240
Other Decks in Programming
See All in Programming
Vibes Containers 〜AIで変わるコンテナ設計と運用〜
tkikuc
3
550
変化を抱擁するドキュメントの作り方 - ビジネスルール駆動開発がもたらす、コードとの新しい関係
ioki
2
200
手動確認はもう限界 〜XCUITestでCustom URL Schemeの遷移を起動種別ごとに自動テストする〜 / Testing Custom URL Schemes with XCUITest
otouto
0
290
Augmenting AI with the Power of Jakarta EE
ivargrimstad
0
110
JPUG勉強会 OSSデータベースの内部構造を理解しよう(第2回)
oga5
0
230
App Intentsのビルドプロセスを支える技術
kntkymt
0
380
Heart of Swift Concurrency
koher
0
810
Snowflakeで業務アプリを作ろう。 Snowflakeのアプリ機能解説&実践ガイド
ayumu_yamaguchi
1
280
{ Android | Kotlin } Gradle Plugin in 2026
ryunen344
1
320
数年滞っていたダークモード対応をおよそ2週間で完了させる
chigichan24
0
710
Security issues being discussed on Web Platforms
petamoriken
0
950
速習iPhone Duo対応
yuukiw00w
1
510
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
250
1.3M
BBQ
matthewcrist
89
10k
A designer walks into a library…
pauljervisheath
211
25k
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
460
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
230
Designing for humans not robots
tammielis
254
26k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
28
3.6k
Making Projects Easy
brettharned
120
6.8k
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
390
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
123
22k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
890
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.6k
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 に置き換える
ご静聴ありがとうございました