Symfony Meetup#13 LT資料
ςετ͜ͱ͡Ί[email protected][F
View Slide
ͳ·͑ɿՖҪɹߦUXJUUFSɿ[email protected][FॴଐɿIJUPNFEJB4ZNGPOZྺɿ̍ 99
テスト書いてない人テスト書くの面倒くさい人
http://cdn-ak.f.st-hatena.com/images/fotolife/w/wakare_re/20151127/20151127221321.png
俺はテスト書くけど、みんなが書いてくれない。。。カバレッジ上がらない。。。つらたん(´・ω・`)
手をあげなかった方は、 テストコードを書く文化が 浸透しているっぽいので、 後ほど詳しく お話を聞かせたいただきたい と思います
書いたほうがいいっていろんな人が言っているからには、何か気づけていない価値があるはず
では、なぜ面倒くさいと感じるか。なぜなくても良いと思ってしまうか。テストを書くと何が嬉しいのか。
可能性[0]「そもそも書き方がわからないですー」説
とりあえず書いてみよう
Q.どこまでの範囲のテストを書くべき?A.テストコード/テスト自動化で解決できるテストの種類は限られる。
継続的デリバリー p129 技術視点 ビジネス視点 支援 評価 機能の受け入れテスト ユニットテストインテグレーションテストシステムテスト ショーケース(デモなど)ユーザビリティテスト探索的テスト 非機能の受け入れテスト(キャパシティ/セキュリティなど) リグレッションテスト 自動化の対象
Q.どれくらいの量のテストを書かないといけない?A.包括的なテストのためには(自動化可能なテスト全てにおいて)80%以上のカバレッジが必要。「継続的デリバリー」 P131-132
継続的デリバリー 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