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
940
マネジメントするときに気をつけていること
kkkw
0
690
社内勉強会 脱!Git初心者
kkkw
0
240
Other Decks in Programming
See All in Programming
Performance Optimization With LLMs
xleitix
0
140
最近”作らせてる” ローカルAIアプリの話
akit37
0
480
ジョジョの世界をXRで再現する
mofurune
0
170
Web Framework Benchmark Battle 2026, Any%
a_matsuda
2
2.5k
[ハンズオン]AIへの指示だけで「五目並べ」を作ってみよう
satoshi256kbyte
1
380
npm との違いを手がかりにGo の依存管理を理解したい
optim
0
800
全ての永続トークンを、生まれる前に消し去りたい!
sylph01
2
980
月間100万人のサービス刷新で、 技術選定をHonoに振り切った話
yutobara
8
6.7k
S3 TablesのIcebergデータに、AIエージェントからアクセスしてみた / 20261016developersio2026joetsu-accessing-iceberg-in-s3tables-via-agent
kasacchiful
PRO
0
170
AIに “答え“を書かせるのを やめてみた
___akari11
0
120
The Rails Doctrine Decade
koic
2
600
re:Inventに行く前に知っておきたい現地参加のノウハウ
nokomoro3
0
440
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
529
40k
Building Better People: How to give real-time feedback that sticks.
wjessup
371
20k
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.7k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
18k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
630
Large-scale JavaScript Application Architecture
addyosmani
516
110k
The Power of CSS Pseudo Elements
geoffreycrofte
82
6.6k
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
310
A Tale of Four Properties
chriscoyier
163
24k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.6k
Become a Pro
speakerdeck
PRO
31
6.3k
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 に置き換える
ご静聴ありがとうございました