テストことはじめ

Symfony Meetup#13 LT資料

Transcript

1. ςετ͜ͱ͸͡Ί
   
   !IBOBIJSP@B[F
   
2. ͳ·͑ɿՖҪɹ޺ߦ
   
   UXJUUFSɿ!IBOBIJSP@B[F
   ॴଐɿIJUPNFEJB
   4ZNGPOZྺɿ̍೥ 99
   
3. テスト書いてない人 テスト書くの面倒くさい人
4. http://cdn-ak.f.st-hatena.com/images/fotolife/w/wakare_re/20151127/20151127221321.png
6. 俺はテスト書くけど、 みんなが書いてくれない。。。 カバレッジ上がらない。。。 つらたん(´・ω・`)
7. 手をあげなかった方は、 テストコードを書く文化が 浸透しているっぽいので、 後ほど詳しく お話を聞かせたいただきたい と思います
8. 書いたほうがいいっていろんな人が 言っているからには、 何か気づけていない価値があるはず
9. では、 なぜ面倒くさいと感じるか。 なぜなくても良いと思ってしまうか。 テストを書くと何が嬉しいのか。
10. 可能性[０] 「そもそも書き方がわからないですー」 説
11. とりあえず書いてみよう
12. Q.どこまでの範囲のテストを 書くべき？ A.テストコード/テスト自動化で 解決できる テストの種類は限られる。
13. 継続的デリバリー　p129 技術視点 ビジネス視点 支 援 評 価 機能の受け入れ テスト ユニットテスト インテグレーションテスト システムテスト ショーケース(デモなど) ユーザビリティテスト 探索的テスト 非機能の受け入れテスト (キャパシティ/セキュリティなど) リグレッション テスト 自動化の対象
14. Q.どれくらいの量のテストを 書かないといけない？ A.包括的なテストのためには (自動化可能なテスト全てにおいて) 80%以上のカバレッジが必要。 「継続的デリバリー」　P131-132
15. 継続的デリバリー　p129 技術視点 ビジネス視点 支 援 評 価 機能の受け入れ テスト ユニットテスト インテグレーションテスト システムテスト ショーケース(デモなど) ユーザビリティテスト 探索的テスト 非機能の受け入れテスト (キャパシティ/セキュリティなど) リグレッション テスト 60% 20% 80% 80%
16. 継続的デリバリー　p129 技術視点 ビジネス視点 支 援 評 価 機能の受け入れ テスト ユニットテスト インテグレーションテスト システムテスト ショーケース(デモなど) ユーザビリティテスト 探索的テスト 非機能の受け入れテスト (キャパシティ/セキュリティなど) リグレッション テスト 60% 20% 80% 80%
17. とはいえ、 いきなり理想像を目指すのは 大変なので、
18. 継続的デリバリー　p129より 技術視点 ビジネス視点 支 援 評 価 機能の受け入れ テスト ユニットテスト インテグレーションテスト システムテスト ショーケース(デモなど) ユーザビリティテスト 探索的テスト 非機能の受け入れテスト (キャパシティ/セキュリティなど) リグレッション テスト ここから始めるのが よさそう。
19. 可能性[１] 「開発中に画面ぽちぽち is enough」 説
20. 「短気なプログラマのためのPHPUnitクックブック」　はじめに 下線は @hanahiro_aze 「自動化されたテストの価値は、 コードの作成や変更を行うときに 明瞭かつ迅速なフィードバックループを 構築するための優れたツールになる。」 「生産的にソフトウェアを開発していく上で、 『前進しているという感覚』は 必要不可欠なんだ。」
21. 画面をぽちぽち触ることで、 「明瞭かつ迅速なフィードバックループ」 が回って、 「前進しているという感覚」 を得ているのではないか。
22. 継続的デリバリー　p129 技術視点 ビジネス視点 支 援 評 価 機能の受け入れ テスト ユニットテスト インテグレーションテスト システムテスト ショーケース(デモなど) ユーザビリティテスト 探索的テスト 非機能の受け入れテスト (キャパシティ/セキュリティなど) リグレッション テスト ここの範囲のみ。
23. http://livedoor.blogimg.jp/hatima/imgs/d/1/d1f50872.jpg 1/3もカバーしてない♫
24. ・画面からでないと、テストできない項目もある。 ・APIの受け入れテスト、ServiceClassのテスト を書くことで、「画面から確認する」+αの 安全性を担保しませんか？ 「1/3もカバーしてない」けれど
25. 「同じ機能に対して手動テストを２回以上 行っていることに気づいたら、 その機能がこの先変更されるかどうか 確かめてみる。」 変更がなさそうなら自動化する。 よく変更されるなら自動化から外す。 継続的デリバリー　p139-140
26. 可能性[２] 「納期・締め切り・時間無い」 説
27. hitomedia 開発合宿での一コマ テスト書くの面倒ですか？ だって仕様きてから１週間後にリリースとかあるんだよ。 テスト書く時間無いじゃん。 Aさん 確かに。(泣)
28. テストする機能を絞ろう！ 「自動テストを導入するための 最善の方法は、最も一般的で価値が高く 重要なユースケースから始めることだ。 そのためには顧客と会話して、 本当のビジネス価値がどこにあるのかを 明確に特定し、その上で、 テストを使ってその機能を リグレッションから守るのだ。」 継続的デリバリー　p139
29. テストする機能を絞ろう！ (例) ・ViewModel/帳票出力のデータ取得 ・バリデーション 継続的デリバリー　p139
30. 設計の正しさを確認するためのテスト テストしづらいコードは設計がイケてな い可能性を疑う。 (例) ・条件分岐の一方はarrayが返るけど、 他方はModelObjectが返ってくる。。。
31. 可能性[３] 「I am ドメインエキスパート」 説
32. hitomedia 開発合宿での一コマ そういえば、なんでテスト書かないで いままでやってきたんですか？ ずっと一人で作ってたし、 仕様がわかりきってるから、書く意味ないと思うんだ。 Aさん 大変でしたね。。泣
33. http://bit.ly/29qgkTr ひとりじゃない〜♫
34. 継続的デリバリー　p129 技術視点 ビジネス視点 支 援 評 価 機能の受け入れ テスト ユニットテスト インテグレーションテスト システムテスト ショーケース(デモなど) ユーザビリティテスト 探索的テスト 非機能の受け入れテスト (キャパシティ/セキュリティなど) リグレッション テスト ここは顧客も 巻き込む。
35. 昨日の自分は他人 ・テストケース=仕様書に寄せていく。 ・設計の正しさの検証をする。
36. 実際に書いてみた
37. 実際に書いてみた
38. ͰɺԿ͕خ͍͠ͷʁ
    ・フィードバックループ ・リグレッション防止 ・書いてみると、実はそんなに難しくない 　(辛いところもあるけど。。。) ・イケてない設計に気づく。
39. ͝੩ௌ
    ͋Γ͕ͱ͏͍͟͝·ͨ͠ɻ
    
40. 参考 ・短気なプログラマのためのPHPUnitクックブック https://leanpub.com/grumpy-phpunit-jp ・継続的デリバリー http://amzn.to/29CHQzq ・アジャイルソフトウェア開発の奥義 http://amzn.to/29wm3M7