Upgrade to Pro — share decks privately, control downloads, hide ads and more …

テストことはじめ

 テストことはじめ

Symfony Meetup#13 LT資料

はない

July 10, 2016
Tweet

More Decks by はない

Other Decks in Technology

Transcript

  1. ςετ͜ͱ͸͡Ί

    [email protected][F

    View Slide

  2. ͳ·͑ɿՖҪɹ޺ߦ
    UXJUUFSɿ[email protected][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. 可能性[0]
    「そもそも書き方がわからないですー」

    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. 可能性[1]
    「開発中に画面ぽちぽち 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. 「同じ機能に対して手動テストを2回以上
    行っていることに気づいたら、
    その機能がこの先変更されるかどうか
    確かめてみる。」
    変更がなさそうなら自動化する。
    よく変更されるなら自動化から外す。
    継続的デリバリー p139-140

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  31. 可能性[3]
    「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