Successfully reported this slideshow.

詳解!自動結合テスト #jasst

7,681 views

Published on

JaSST 13 九州での発表資料です。

Published in: Technology
  • Be the first to comment

詳解!自動結合テスト #jasst

  1. 1. 詳解!自動結合テスト kyon_mm 2013/11/1 jasst’ 13 Kyushu Web A u tom ate In te grati on Te st ing
  2. 2. 自己紹介 きょん(@kyon_mm) ソフトウェアテストアーキテクト うさみみ系エンジニア Groovy, C#, F#, Ruby, Scala SCMBootCamp, TDDBootCamp, 基礎勉強会, Nagoya.Testing, Cafe.Testing, STAR, TDDeXchange
  3. 3. アジェンダ 私の背景(Webアプリ中心とかチームが優秀とか) 品質を保つ自動テスト(どの立場で関わるのか大 切) テスト設計について(共有しやすい形とか) 詳細はイブニングセッション! 取り組み方(Groovy系, C#系, Scala系) 詳細はイブニングセッション!
  4. 4. 私の背景 開発対象 .NETで動くサーバーサイドのメッセージ型の Webアプリケーション。RESTfulAPI的な。 たまにGUIもあり。 HTTPでXMLとかJSONを交換する感じ。
  5. 5. 私の背景 開発規模 1ヶ月から3ヶ月くらいが多い。大きいと1年。 開発人数 社内チームはマネージャー含めて2 - 4人が多 い。 他ベンダーと協調して作る事が多い。
  6. 6. 私の背景 開発者 優秀だと言い張れるくらいには優秀 お互いを尊敬し合いながら意見交換できる 綺麗なコードが正義であり、自動化された単 体テストがないプロダクトはあり得ないとい う文化
  7. 7. アジェンダ 私の背景(Webアプリ中心とかチームが優秀とか) 品質を保つ自動テスト(どの立場で関わるのか大 切) テスト設計について(共有しやすい形とか) 取り組み方(Groovy系, C#系, Scala系)
  8. 8. 品質を保つ自動テスト 【まえがき】テストのコスト意識はとても重要 です。テストのコスト意識はとても重要です。
  9. 9. 品質を保つ自動テスト テストの自動化は何度も実行しなければもとが 取れないとかいう話があります。
  10. 10. 品質を保つ自動テスト 自動化は3回やらない と元がとれない? 目を覚ませ。建前はい らないのだよ。
  11. 11. 品質を保つ自動テスト テストの自動化は何度も実行しなければもとが 取れないとかいう話がありますが、そういうの は建前です。嘘です。いい訳です。 「結合テスト自動化で得られる最大のメリット はテスト実装者が得る幅広いプログラミングス キルとアーキテクチャ知識である」 「手動では不可能なテストの実装、コストの大 幅低減」を実現するのは多くはシステムテスト レベルである事が(比較的)多い。
  12. 12. 品質を保つ自動テスト 「結合テスト自動化で得られる最大のメリット はテスト実装者が得る幅広いプログラミングス キルとアーキテクチャ知識である」 結合テストレベルの自動化をしなくていいと言 っているのは、上のメリットを「(優先順位を考 慮して)必要ない」と言っているのと同義だと捉 えていると考え直してから決定する。
  13. 13. 品質を保つ自動テスト 自動テストを誰かが勝手にやってくれるものと して保証する 自動テストを自分の手足のように使う(理解す る)ものとして保証する 自動テストなしで保証する どの立場でテストを行うかはあなた次第
  14. 14. アジェンダ 私の背景(Webアプリ中心とかチームが優秀とか) 品質を保つ自動テスト(どの立場で関わるのか大 切) テスト設計について(共有しやすい形とか) 取り組み方(Groovy系, C#系, Scala系)
  15. 15. テスト設計について テストプロセスで重要なもの 見積もり 優先順位の変更 実装のスケール 保守 実施のスケール
  16. 16. テスト設計について EmacsのOrg-Mode表記 (個人的にオススメ UserStory + 6W2H マインドマップ (個人的にオススメ マトリクス オブジェクト図
  17. 17. アジェンダ 私の背景(Webアプリ中心とかチームが優秀とか) 品質を保つ自動テスト(どの立場で関わるのか大 切) テスト設計について(共有しやすい形とか) 取り組み方(Groovy系, C#系, Scala系)
  18. 18. 取り組み方 Groovy Spock : 表形式とコメントを豊富につけられ るテスティングフレームワーク AsyncHttpClient : Httpのクライアントとし て高性能な非同期通信ライブラリ Geb : WebDriverをベースにしたWebGUI操作の テストライブラリ
  19. 19. 取り組み方 C# TestAPI : 因子水準の組み合わせ、豊富な値 ランダム生成などを持っているライブラリ WebHttpClient : 標準のWebClient NUnit : C# のテスティングフレームワーク EntityFramework : ORマッパー
  20. 20. 取り組み方 Scala Gatling : HTTPでの性能テストフレームワー ク。普通のWebClientなテストフレームワーク としても使える。 ScalikeJDBC : DB操作のためのORマッパー
  21. 21. 自動テストの悪用 社内外で自動テストを経験してわかったこと が2つある。 自動結合テスト TDD
  22. 22. 自動結合テスト 結合テストの自動化のROIで実行回数に目がい くのか? 結合テストの自動化で意味があるものは?
  23. 23. 自動結合テスト 結合テストの自動化がうまくいっているとは どういうことか 保守性? 属個人性?
  24. 24. 自動結合テスト 自動結合テストが「うまくいっている」と思 い込んでしまうパターンがある。 「無駄なテストを大量に増やせる事」 「効果がありそうなんだけど無駄なテスト」 をいかに減らせるかが鍵になってくる。
  25. 25. 自動結合テスト 効果的な自動結合テストとはどうすればつく れるのか?
  26. 26. 自動結合テスト 結合テストを減らすには、結合テストより前 の段階でどうやって減らすかにかかってい る。 テストで減らす : 結合テストより下のテス トと「網羅対象や度合い」をテスト設計する 設計で減らす:結合テストでの因子水準を減 らせるようなプロダクト設計する
  27. 27. 自動結合テスト プロダクトコードをレビ ューできるスキルがない なら、 効果的な自動結合テスト は不可能に近い。
  28. 28. 自動結合テスト 効果的な自動テストはなにかを考えないと、 「自動化対象外と協調したテスト設計をおろ そかにする」 自動化対象のテストのみに着目するので 「ROI=予想実行回数」のような発想になる。
  29. 29. 自動テストの悪用 社内外で自動テストを経験してわかったこと が2つある。 自動結合テスト TDD
  30. 30. Definition TDD 1. 失敗するテストコードを実装する 2. テストが通る最低限の実装をする 3. 1と2を繰り返す中で、テストの変更につよ くするための実装をする 1 - 3を30secから1minで繰り返す。
  31. 31. TDD TDDをして品質があがると思う人が多くいる。 一方で上がらないと思っている人がいる。 (効果のある品質特性が異なるという話では ないよ。
  32. 32. Good TDD 強制的に検査されたプロダクトしか手に入ら なくなる事によって、つまらないバグが減 る。 最低限のテスト、最低限のプロダクトのみに よって進められるサイクルによって得られる 本質に近づくための知識を取得できる。
  33. 33. Bad TDD あるコミュニティにとってTDDは成功しやすい 手法かもしれないが、失敗する場合もある。 例 AdaコンパイラはTDDを採用したが、よろしく ないTDDを行ってしまって、今までにないバ グを発生させた。
  34. 34. Why Fail TDDが難しいから? TDDでカバレッジ100%を目指したから? 自動テストの実行結果がオールグリーンのス クリーンショットをExcelにはったから? 上3つをクリアしても失敗する原因がある
  35. 35. Why Fail TDDはコードを増やすことになっている。 低スキルなプログラマーが「プロダクト」だ としても「テスト」だとしても書くのは「ひ どいコード」であることには変わりない。 でも、意味の通じないドキュメントを書いて しまうことよりはずっとマシ :-p 言い換えれば、TDDで効果があがるのは、属個 人性の排除と、意味の通じないドキュメント によって生み出されるバグ予防、確認不足の 予防

×