テストことはじめ

Symfony Meetup#13 LT資料

Transcript

1. ςετ͜ͱ͸͡Ί
   
   !IBOBIJSP@B[F
   

   View Slide

2. ͳ·͑ɿՖҪɹ޺ߦ
   UXJUUFSɿ!IBOBIJSP@B[F
   ॴଐɿIJUPNFEJB
   4ZNGPOZྺɿ̍೥ 99
   
   

   View Slide

3. テスト書いてない人
   テスト書くの面倒くさい人
   
   

   View Slide

4. http://cdn-ak.f.st-hatena.com/images/fotolife/w/wakare_re/20151127/20151127221321.png
   

   View Slide

5. View Slide

6. 俺はテスト書くけど、
   みんなが書いてくれない。。。
   カバレッジ上がらない。。。
   つらたん(´・ω・`)
   
   

   View Slide

7. 手をあげなかった方は、
   テストコードを書く文化が
   浸透しているっぽいので、
   後ほど詳しく
   お話を聞かせたいただきたい
   と思います
   

   View Slide

8. 書いたほうがいいっていろんな人が
   言っているからには、
   何か気づけていない価値があるはず
   

   View Slide

9. では、
   なぜ面倒くさいと感じるか。
   なぜなくても良いと思ってしまうか。
   テストを書くと何が嬉しいのか。
   

   View Slide

10. 可能性[０]
    「そもそも書き方がわからないですー」
    説
    

    View Slide

11. とりあえず書いてみよう
    

    View Slide

12. Q.どこまでの範囲のテストを
    書くべき？
    A.テストコード/テスト自動化で
    解決できる
    テストの種類は限られる。
    

    View Slide

13. 継続的デリバリー　p129
    技術視点
    ビジネス視点
    支
    援
    
    評
    価
    
    機能の受け入れ
    テスト
    ユニットテスト
    インテグレーションテスト
    システムテスト
    ショーケース(デモなど)
    ユーザビリティテスト
    探索的テスト
    非機能の受け入れテスト
    (キャパシティ/セキュリティなど)
    リグレッション
    テスト
    自動化の対象
    

    View Slide

14. Q.どれくらいの量のテストを
    書かないといけない？
    A.包括的なテストのためには
    (自動化可能なテスト全てにおいて)
    80%以上のカバレッジが必要。
    「継続的デリバリー」　P131-132
    

    View Slide

15. 継続的デリバリー　p129
    技術視点
    ビジネス視点
    支
    援
    
    評
    価
    
    機能の受け入れ
    テスト
    ユニットテスト
    インテグレーションテスト
    システムテスト
    ショーケース(デモなど)
    ユーザビリティテスト
    探索的テスト
    非機能の受け入れテスト
    (キャパシティ/セキュリティなど)
    リグレッション
    テスト
    60% 20%
    80%
    80%
    

    View Slide

16. 継続的デリバリー　p129
    技術視点
    ビジネス視点
    支
    援
    
    評
    価
    
    機能の受け入れ
    テスト
    ユニットテスト
    インテグレーションテスト
    システムテスト
    ショーケース(デモなど)
    ユーザビリティテスト
    探索的テスト
    非機能の受け入れテスト
    (キャパシティ/セキュリティなど)
    リグレッション
    テスト
    60% 20%
    80%
    80%
    

    View Slide

17. とはいえ、
    いきなり理想像を目指すのは
    大変なので、
    

    View Slide

18. 継続的デリバリー　p129より
    技術視点
    ビジネス視点
    支
    援
    
    評
    価
    
    機能の受け入れ
    テスト
    ユニットテスト
    インテグレーションテスト
    システムテスト
    ショーケース(デモなど)
    ユーザビリティテスト
    探索的テスト
    非機能の受け入れテスト
    (キャパシティ/セキュリティなど)
    リグレッション
    テスト
    ここから始めるのが
    よさそう。
    

    View Slide

19. 可能性[１]
    「開発中に画面ぽちぽち is enough」
    説
    

    View Slide

20. 「短気なプログラマのためのPHPUnitクックブック」　はじめに
    下線は @hanahiro_aze
    「自動化されたテストの価値は、
    コードの作成や変更を行うときに
    明瞭かつ迅速なフィードバックループを
    構築するための優れたツールになる。」
    「生産的にソフトウェアを開発していく上で、
    『前進しているという感覚』は
    必要不可欠なんだ。」
    

    View Slide

21. 画面をぽちぽち触ることで、
    「明瞭かつ迅速なフィードバックループ」
    が回って、
    「前進しているという感覚」
    を得ているのではないか。
    

    View Slide

22. 継続的デリバリー　p129
    技術視点
    ビジネス視点
    支
    援
    
    評
    価
    
    機能の受け入れ
    テスト
    ユニットテスト
    インテグレーションテスト
    システムテスト
    ショーケース(デモなど)
    ユーザビリティテスト
    探索的テスト
    非機能の受け入れテスト
    (キャパシティ/セキュリティなど)
    リグレッション
    テスト
    ここの範囲のみ。
    

    View Slide

23. http://livedoor.blogimg.jp/hatima/imgs/d/1/d1f50872.jpg
    1/3もカバーしてない♫
    

    View Slide

24. ・画面からでないと、テストできない項目もある。
    ・APIの受け入れテスト、ServiceClassのテスト
    を書くことで、「画面から確認する」+αの
    安全性を担保しませんか？
    「1/3もカバーしてない」けれど
    

    View Slide

25. 「同じ機能に対して手動テストを２回以上
    行っていることに気づいたら、
    その機能がこの先変更されるかどうか
    確かめてみる。」
    変更がなさそうなら自動化する。
    よく変更されるなら自動化から外す。
    継続的デリバリー　p139-140
    

    View Slide

26. 可能性[２]
    「納期・締め切り・時間無い」
    説
    

    View Slide

27. hitomedia 開発合宿での一コマ
    テスト書くの面倒ですか？
    だって仕様きてから１週間後にリリースとかあるんだよ。
    テスト書く時間無いじゃん。 Aさん
    確かに。(泣)
    

    View Slide

28. テストする機能を絞ろう！
    「自動テストを導入するための
    最善の方法は、最も一般的で価値が高く
    重要なユースケースから始めることだ。
    そのためには顧客と会話して、
    本当のビジネス価値がどこにあるのかを
    明確に特定し、その上で、
    テストを使ってその機能を
    リグレッションから守るのだ。」
    継続的デリバリー　p139
    

    View Slide

29. テストする機能を絞ろう！
    (例)
    ・ViewModel/帳票出力のデータ取得
    ・バリデーション
    継続的デリバリー　p139
    

    View Slide

30. 設計の正しさを確認するためのテスト
    テストしづらいコードは設計がイケてな
    い可能性を疑う。
    (例)
    ・条件分岐の一方はarrayが返るけど、
    他方はModelObjectが返ってくる。。。
    

    View Slide

31. 可能性[３]
    「I am ドメインエキスパート」
    説
    

    View Slide

32. hitomedia 開発合宿での一コマ
    そういえば、なんでテスト書かないで
    いままでやってきたんですか？
    ずっと一人で作ってたし、
    仕様がわかりきってるから、書く意味ないと思うんだ。
    Aさん
    大変でしたね。。泣
    

    View Slide

33. http://bit.ly/29qgkTr
    ひとりじゃない〜♫
    

    View Slide

34. 継続的デリバリー　p129
    技術視点
    ビジネス視点
    支
    援
    
    評
    価
    
    機能の受け入れ
    テスト
    ユニットテスト
    インテグレーションテスト
    システムテスト
    ショーケース(デモなど)
    ユーザビリティテスト
    探索的テスト
    非機能の受け入れテスト
    (キャパシティ/セキュリティなど)
    リグレッション
    テスト
    ここは顧客も
    巻き込む。
    

    View Slide

35. 昨日の自分は他人
    ・テストケース=仕様書に寄せていく。
    ・設計の正しさの検証をする。
    

    View Slide

36. 実際に書いてみた
    

    View Slide

37. 実際に書いてみた
    
    

    View Slide

38. ͰɺԿ͕خ͍͠ͷʁ
    ・フィードバックループ
    ・リグレッション防止
    ・書いてみると、実はそんなに難しくない
    　(辛いところもあるけど。。。)
    ・イケてない設計に気づく。
    

    View Slide

39. ͝੩ௌ
    ͋Γ͕ͱ͏͍͟͝·ͨ͠ɻ
    

    View Slide

40. 参考
    ・短気なプログラマのためのPHPUnitクックブック
    https://leanpub.com/grumpy-phpunit-jp
    ・継続的デリバリー
    http://amzn.to/29CHQzq
    ・アジャイルソフトウェア開発の奥義
    http://amzn.to/29wm3M7
    
    

    View Slide