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
450
テストことはじめ
Symfony Meetup#13 LT資料
はない
July 10, 2016
Tweet
Share
More Decks by はない
See All by はない
2018年目標を達成できなかった私が 今年こそ達成するためにしていること
hanahiroaze
3
490
組み合わせテストを簡単にするgemを作った話
hanahiroaze
0
230
MySQLとデッドロックの話
hanahiroaze
1
1.3k
ここが変だよ。このテスト〜テストケース爆発と戦う〜
hanahiroaze
1
1.5k
Symfony Best Practiceを読もう!(ついでに翻訳した話)
hanahiroaze
2
880
E2E Test Tips
hanahiroaze
0
160
Symfony2のi18n対応
hanahiroaze
0
770
開発合宿に行ってきました
hanahiroaze
0
140
GitHubよちよち会#3
hanahiroaze
0
160
Other Decks in Technology
See All in Technology
KubeCon + CloudNativeCon Japan 2025 に行ってきた! & containerd の新機能紹介
honahuku
0
120
Witchcraft for Memory
pocke
1
750
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
160
Tech-Verse 2025 Global CTO Session
lycorptech_jp
PRO
0
1.6k
敢えて生成AIを使わないマネジメント業務
kzkmaeda
1
330
MobileActOsaka_250704.pdf
akaitadaaki
0
110
生成AIで小説を書くためにプロンプトの制約や原則について学ぶ / prompt-engineering-for-ai-fiction
nwiizo
6
4.1k
ゼロからはじめる採用広報
yutadayo
1
180
B2C&B2B&社内向けサービスを抱える開発組織におけるサービス価値を最大化するイニシアチブ管理
belongadmin
1
5.7k
PO初心者が考えた ”POらしさ”
nb_rady
0
190
赤煉瓦倉庫勉強会「Databricksを選んだ理由と、絶賛真っ只中のデータ基盤移行体験記」
ivry_presentationmaterials
2
300
ネットワーク保護はどう変わるのか?re:Inforce 2025最新アップデート解説
tokushun
0
180
Featured
See All Featured
Site-Speed That Sticks
csswizardry
10
680
A Modern Web Designer's Workflow
chriscoyier
694
190k
RailsConf 2023
tenderlove
30
1.1k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
The Language of Interfaces
destraynor
158
25k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
Bash Introduction
62gerente
614
210k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Done Done
chrislema
184
16k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
The Invisible Side of Design
smashingmag
301
51k
Music & Morning Musume
bryan
46
6.6k
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