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
はない
July 10, 2016
Technology
0
470
テストことはじめ
Symfony Meetup#13 LT資料
はない
July 10, 2016
Tweet
Share
More Decks by はない
See All by はない
2018年目標を達成できなかった私が 今年こそ達成するためにしていること
hanahiroaze
3
500
組み合わせテストを簡単にするgemを作った話
hanahiroaze
0
230
MySQLとデッドロックの話
hanahiroaze
1
1.3k
ここが変だよ。このテスト〜テストケース爆発と戦う〜
hanahiroaze
1
1.6k
Symfony Best Practiceを読もう!(ついでに翻訳した話)
hanahiroaze
2
900
E2E Test Tips
hanahiroaze
0
160
Symfony2のi18n対応
hanahiroaze
0
790
開発合宿に行ってきました
hanahiroaze
0
140
GitHubよちよち会#3
hanahiroaze
0
170
Other Decks in Technology
See All in Technology
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
43k
AIフル活用で挑む!空間アプリ開発のリアル
taat
0
110
Azureコストと向き合った、4年半のリアル / Four and a half years of dealing with Azure costs
aeonpeople
1
240
Introdução a Service Mesh usando o Istio
aeciopires
1
260
AIとともに歩んでいくデザイナーの役割の変化
lycorptech_jp
PRO
0
690
だいたい分かった気になる 『SREの知識地図』 / introduction-to-sre-knowledge-map-book
katsuhisa91
PRO
0
420
OpenTelemetry が拡げる Gemini CLI の可観測性
phaya72
2
950
速習AGENTS.md:5分で精度を上げる "3ブロック" テンプレ
ismk
6
1.9k
Dylib Hijacking on macOS: Dead or Alive?
patrickwardle
0
420
WEBサービスを成り立たせるAWSサービス
takano0131
1
190
CREが作る自己解決サイクルSlackワークフローに組み込んだAIによる社内ヘルプデスク改革 #cre_meetup
bengo4com
0
130
OCIjp_Oracle AI World_Recap
shinpy
1
120
Featured
See All Featured
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
22k
Scaling GitHub
holman
463
140k
Speed Design
sergeychernyshev
32
1.2k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
920
Practical Orchestrator
shlominoach
190
11k
Making Projects Easy
brettharned
120
6.4k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Mobile First: as difficult as doing things right
swwweet
225
10k
Bash Introduction
62gerente
615
210k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
Automating Front-end Workflow
addyosmani
1371
200k
Navigating Team Friction
lara
190
15k
Transcript
ςετ͜ͱ͡Ί !IBOBIJSP@B[F
ͳ·͑ɿՖҪɹߦ UXJUUFSɿ!IBOBIJSP@B[F ॴଐɿIJUPNFEJB 4ZNGPOZྺɿ̍ 99
テスト書いてない人 テスト書くの面倒くさい人
http://cdn-ak.f.st-hatena.com/images/fotolife/w/wakare_re/20151127/20151127221321.png
None
俺はテスト書くけど、 みんなが書いてくれない。。。 カバレッジ上がらない。。。 つらたん(´・ω・`)
手をあげなかった方は、 テストコードを書く文化が 浸透しているっぽいので、 後ほど詳しく お話を聞かせたいただきたい と思います
書いたほうがいいっていろんな人が 言っているからには、 何か気づけていない価値があるはず
では、 なぜ面倒くさいと感じるか。 なぜなくても良いと思ってしまうか。 テストを書くと何が嬉しいのか。
可能性[0] 「そもそも書き方がわからないですー」 説
とりあえず書いてみよう
Q.どこまでの範囲のテストを 書くべき? A.テストコード/テスト自動化で 解決できる テストの種類は限られる。
継続的デリバリー p129 技術視点 ビジネス視点 支 援 評 価 機能の受け入れ テスト ユニットテスト
インテグレーションテスト システムテスト ショーケース(デモなど) ユーザビリティテスト 探索的テスト 非機能の受け入れテスト (キャパシティ/セキュリティなど) リグレッション テスト 自動化の対象
Q.どれくらいの量のテストを 書かないといけない? A.包括的なテストのためには (自動化可能なテスト全てにおいて) 80%以上のカバレッジが必要。 「継続的デリバリー」 P131-132
継続的デリバリー p129 技術視点 ビジネス視点 支 援 評 価 機能の受け入れ テスト ユニットテスト
インテグレーションテスト システムテスト ショーケース(デモなど) ユーザビリティテスト 探索的テスト 非機能の受け入れテスト (キャパシティ/セキュリティなど) リグレッション テスト 60% 20% 80% 80%
継続的デリバリー p129 技術視点 ビジネス視点 支 援 評 価 機能の受け入れ テスト ユニットテスト
インテグレーションテスト システムテスト ショーケース(デモなど) ユーザビリティテスト 探索的テスト 非機能の受け入れテスト (キャパシティ/セキュリティなど) リグレッション テスト 60% 20% 80% 80%
とはいえ、 いきなり理想像を目指すのは 大変なので、
継続的デリバリー p129より 技術視点 ビジネス視点 支 援 評 価 機能の受け入れ テスト ユニットテスト
インテグレーションテスト システムテスト ショーケース(デモなど) ユーザビリティテスト 探索的テスト 非機能の受け入れテスト (キャパシティ/セキュリティなど) リグレッション テスト ここから始めるのが よさそう。
可能性[1] 「開発中に画面ぽちぽち is enough」 説
「短気なプログラマのためのPHPUnitクックブック」 はじめに 下線は @hanahiro_aze 「自動化されたテストの価値は、 コードの作成や変更を行うときに 明瞭かつ迅速なフィードバックループを 構築するための優れたツールになる。」 「生産的にソフトウェアを開発していく上で、 『前進しているという感覚』は 必要不可欠なんだ。」
画面をぽちぽち触ることで、 「明瞭かつ迅速なフィードバックループ」 が回って、 「前進しているという感覚」 を得ているのではないか。
継続的デリバリー p129 技術視点 ビジネス視点 支 援 評 価 機能の受け入れ テスト ユニットテスト
インテグレーションテスト システムテスト ショーケース(デモなど) ユーザビリティテスト 探索的テスト 非機能の受け入れテスト (キャパシティ/セキュリティなど) リグレッション テスト ここの範囲のみ。
http://livedoor.blogimg.jp/hatima/imgs/d/1/d1f50872.jpg 1/3もカバーしてない♫
・画面からでないと、テストできない項目もある。 ・APIの受け入れテスト、ServiceClassのテスト を書くことで、「画面から確認する」+αの 安全性を担保しませんか? 「1/3もカバーしてない」けれど
「同じ機能に対して手動テストを2回以上 行っていることに気づいたら、 その機能がこの先変更されるかどうか 確かめてみる。」 変更がなさそうなら自動化する。 よく変更されるなら自動化から外す。 継続的デリバリー p139-140
可能性[2] 「納期・締め切り・時間無い」 説
hitomedia 開発合宿での一コマ テスト書くの面倒ですか? だって仕様きてから1週間後にリリースとかあるんだよ。 テスト書く時間無いじゃん。 Aさん 確かに。(泣)
テストする機能を絞ろう! 「自動テストを導入するための 最善の方法は、最も一般的で価値が高く 重要なユースケースから始めることだ。 そのためには顧客と会話して、 本当のビジネス価値がどこにあるのかを 明確に特定し、その上で、 テストを使ってその機能を リグレッションから守るのだ。」 継続的デリバリー p139
テストする機能を絞ろう! (例) ・ViewModel/帳票出力のデータ取得 ・バリデーション 継続的デリバリー p139
設計の正しさを確認するためのテスト テストしづらいコードは設計がイケてな い可能性を疑う。 (例) ・条件分岐の一方はarrayが返るけど、 他方はModelObjectが返ってくる。。。
可能性[3] 「I am ドメインエキスパート」 説
hitomedia 開発合宿での一コマ そういえば、なんでテスト書かないで いままでやってきたんですか? ずっと一人で作ってたし、 仕様がわかりきってるから、書く意味ないと思うんだ。 Aさん 大変でしたね。。泣
http://bit.ly/29qgkTr ひとりじゃない〜♫
継続的デリバリー p129 技術視点 ビジネス視点 支 援 評 価 機能の受け入れ テスト ユニットテスト
インテグレーションテスト システムテスト ショーケース(デモなど) ユーザビリティテスト 探索的テスト 非機能の受け入れテスト (キャパシティ/セキュリティなど) リグレッション テスト ここは顧客も 巻き込む。
昨日の自分は他人 ・テストケース=仕様書に寄せていく。 ・設計の正しさの検証をする。
実際に書いてみた
実際に書いてみた
ͰɺԿ͕خ͍͠ͷʁ ・フィードバックループ ・リグレッション防止 ・書いてみると、実はそんなに難しくない (辛いところもあるけど。。。) ・イケてない設計に気づく。
͝੩ௌ ͋Γ͕ͱ͏͍͟͝·ͨ͠ɻ
参考 ・短気なプログラマのためのPHPUnitクックブック https://leanpub.com/grumpy-phpunit-jp ・継続的デリバリー http://amzn.to/29CHQzq ・アジャイルソフトウェア開発の奥義 http://amzn.to/29wm3M7