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
950
マネジメントするときに気をつけていること
kkkw
0
690
社内勉強会 脱!Git初心者
kkkw
0
240
Other Decks in Programming
See All in Programming
느린 네트워크와 저사양 디바이스 사용자를 위한 웹뷰 로딩 시간 개선기
kmkim
1
220
AI時代のFlutter品質設計 — アプリ品質を守るQuality Layers
omatty198
0
370
作れる、でも消せるか?──安全に「枯らして消す」機能削除術 / Drain, Then Delete
chobishiba
3
1.5k
複数ドメインを一つのアプリに統合するFlutterの設計と運用_FlutterKaigi2026登壇資料(須永高弘)
takahirosunaga
0
170
SODA - FACT BOOK(JP)
sodainc
1
40k
Enforcing Your Architecture with Unit Tests in the AI Era (Swift Connection X)
steliosf
PRO
1
160
オーケストレーション記述言語 Katari
yukikurage
0
250
Materialが消えた日 〜真っ白なFlutterキャンバスにRenderObjectで絵を描く〜
umigishiaoi
0
160
[DroidKnights 2026] Workflow AX: From Auto-Documented Policies to E2E Testing
raeminkang
0
560
[JA] Domain Modeling with Vanilla Rails: 「操作」から再考するRailsの設計論
yasaichi
4
1.9k
Goコンパイラを作ってGoをもっと理解する / Build a Go compiler to better understand Go
ikura_hamu
0
130
AI時代のTerminal環境を UNIX哲学で設計・運用する
yasunori0418
1
350
Featured
See All Featured
Paper Plane (Part 1)
katiecoart
PRO
3
12k
Scaling GitHub
holman
464
140k
Ten Tips & Tricks for a 🌱 transition
stuffmc
1
280
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
1.1k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
660
XXLCSS - How to scale CSS and keep your sanity
sugarenia
250
1.3M
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
930
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
2
510
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
3.1k
KATA
mclloyd
PRO
35
16k
Optimizing for Happiness
mojombo
378
71k
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
1
370
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 に置き換える
ご静聴ありがとうございました