自動テストの誤解とアンチパターン in 楽天 Tech Talk

23,269 views
22,684 views

Published on

2014/02/12の楽天Tech Talkに登壇させてもらったときの発表スライドです。
2013年に発表したいくつかの内容をまとめました。
基本的に、ソフトウェアテストの絶望を聞きたい人向けです。

Published in: Technology
0 Comments
110 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
23,269
On SlideShare
0
From Embeds
0
Number of Embeds
1,520
Actions
Shares
0
Downloads
142
Comments
0
Likes
110
Embeds 0
No embeds

No notes for slide

自動テストの誤解とアンチパターン in 楽天 Tech Talk

  1. 1. 自動テストの誤解と アンチパターン by kyon_mm in Rakuten Tech Talk 12/02/2014 A u tom ate Te st ing An ti-p atter n
  2. 2. Self Introduction きょん(@kyon_mm) テストアーキテクト Groovy, C#, F#, Scala SCMBootCamp, Nagoya.Testing, TDDBootCamp
  3. 3. Agenda 自動統合テスト 誤解と効果 TDD/BDDについて 歴史 TDDの自殺 失敗するTDD
  4. 4. Agenda 自動統合テスト 誤解と効果 TDD/BDDについて 歴史 TDDの自殺 失敗するTDD
  5. 5. Test Level 単体テスト/コンポーネントテスト 「それらで はアプリケーションとして成立しないファイル 群に対するテスト」 統合テスト「デプロイされている状態でのアプ リケーションに対するテスト」 システムテスト「デプロイされていて、シナリ オも含めたテスト」
  6. 6. Attention テストは手動/自動に関わらずコスト意識が大切 です。 自動化しても見合わないこともあるし、手動で 続けるのが見合わないこともあります。 見合う見合わずではなくとも、どれくらいのコ ストであるかを見積もる、計測する事は大切な 事が多いです。(開発規模が大きくなるほ ど。)
  7. 7. Test ROI テストの自動化は何度も実行しなければもとが 取れないとかいう話があります。 よく3回以上と言われています。
  8. 8. Test ROI 自動化は3回やらない と元がとれない? 目を覚ませ。建前はい らないのだよ。
  9. 9. Test ROI テストの自動化は何度も実行しなければもとが 取れないとかいう話がありますが、そういうの は建前です。嘘です。いい訳です。 「統合テスト自動化で得られる最大のメリット はテスト実装者が得る幅広いプログラミングス キルとアーキテクチャ知識である」 「手動では不可能なテストの実装、コストの大 幅低減」を実現するのは多くはシステムテスト レベルである事が(比較的)多い。
  10. 10. Test ROI 「統合テスト自動化で得られる最大のメリット はテスト実装者が得る幅広いプログラミングス キルとアーキテクチャ知識である」 統合テストレベルの自動化をしなくていいと言 っているのは、上のメリットを「(優先順位を考 慮して)必要ない」と言っているのと同義だと捉 えていることを忘れてはいけない。
  11. 11. Test ROI 自動テストを誰かが勝手にやってくれるものと して保証する 自動テストを自分の手足のように使う(理解す る)ものとして保証する 自動テストなしで保証する どの立場でテストを行うかはあなた次第
  12. 12. Test ROI 例えば。。。 誰かが品質に対して警鐘を鳴らしてくれればよ い。というのは、かなり手慣れた領域での話で ある。 初めての「ドメイン」「大規模化」「複雑化」 「汎用化」などにおいては、知識の不足が露呈 しやすく、効率よく知識を得る必要がある。
  13. 13. Integration Test 統合テストの自動化のROIで実行回数に目がい くのか? 統合テストの自動化で意味があるものは?
  14. 14. Integration Test 統合テストの自動化がうまくいっているとは どういうことか 保守性? 属個人性?
  15. 15. Integration Test 自動統合テストが「うまくいっている」と思 い込んでしまうパターンがある。 「無駄なテストを大量に増やせる事」 「効果がありそうなんだけど無駄なテスト」 をいかに減らせるかが鍵になってくる。
  16. 16. Integration Test 効果的な自動統合テストとはどうすればつく れるのか?
  17. 17. Reduction 統合テストを減らすには、統合テストより前 の段階でどうやって減らすかにかかってい る。 テストで減らす : 統合テストより下のテス トと「網羅対象や度合い」をテスト設計する 設計で減らす:統合テストでの因子水準を減 らせるようなプロダクト設計する
  18. 18. Integration Test プロダクトコードをレビ ューできるスキルがない なら、 効果的な自動統合テスト は不可能に近い。
  19. 19. Test ROI 効果的な自動テストはなにかを考えないと、 「自動化対象外と協調したテスト設計をおろ そかにする」 自動化対象のテストのみに着目するので 「ROI=予想実行回数」のような発想になる。
  20. 20. Agenda 自動統合テスト 誤解と効果 TDD/BDDについて 歴史 TDDの自殺 失敗するTDD
  21. 21. TDD/BDD TDD=Test Driven Development BDD=Behavior Driven Development
  22. 22. History of TDD/BDD TDDというものはSmalltalk界隈の人達の習慣を 洗練させ形式化したものでした。 それをしたのがKentBeckです。 彼を中心にMartin Fowler, Uncle Bob, Ron JeffriesなどがTDDとリファクタリングを洗練さ せていきます。
  23. 23. Kent Beck says... 自動テストが失敗した場合だけ、 新しいコード を書く。 重複を取り除く。2つの規則はプログ ラミングのタスクにおける順番を意味する。 レッド ‐ 動作しないテストを少しだけ作成す る。 おそらく最初はコンパイルできない。 グリーン ‐ テストをすぐに動作させる。 その ためには、 どのようなコードでもよい。 リファクタリング ‐ テストを動作させるため だけに作成された重複をすべて取り除く。
  24. 24. Uncle Bob says... 3つの原則を守りながら実装をすすめる。 失敗するテストができるまでプロダクトを書い てはいけない 失敗するテストがある場合にはそれ以上テスト を追加してはいけない テストを成功させるプロダクトがある場合には それ以上プロダクトを追加してはいけない
  25. 25. t_wada says... プログラマーを含めた開発の健康をたもつプラ クティス RED - GREEN - REFACTORの黄金の回転を回す 動くけど汚ないコード - 動いて美しいコード 動かないコードの状態遷移
  26. 26. kyon_mm says ソフトウェア開発者支援フレームワークである RED - GREEN - REFACTOR のスパイラルモデルが 根幹にある 「開発者の意図を確認すること」「開発者が心 地よいコードを書き始める事」を支援する。
  27. 27. Descended from origin TDD By Example[テスト駆動開発入門] By KentBeck Refactoring[リファクタリング] By Martin Fowler [アジャイル開発の奥義-オブジェクト指向開発 の原則-] By Uncle Bob Clean Code By Uncle Bob JUnit By Kent Beck NUnit By Ron Jeffries
  28. 28. XP アジャイルの一形態であるeXtreme Programming(XP)では 様々なプラクティスが提 案されました。 その中にも「受け入れテストの 自動化」は存在します。 これによって常にプロ ダクトに対して要求に近い検査を行うことが可 能になりました。 XPが直接ではないですが、この頃からATDDとい う概念が生まれはじめます。 このときのATDDは まさに「オンサイト顧客」などのいわゆる 「ユ ーザーのための受け入れテスト」でTDDするとい うものでした。
  29. 29. FIT Framework for Integrated Test(FIT) TDDやXP が広まるなかでより言語に依存しない形でのテ スト(特にIntegration Test)に 注目されるよう になった。 ノンプログラマーにフレンドリーであり、実行 でき、実装すべきモノがみえるテスト
  30. 30. Fit/FitNesse FITの有名な実装としてFit/FitNesseが存在す る。 Ward CunninghamによるFit. Uncle Bobによる FitNesse. 次のような要素からなる。 Wiki上でテストケースを表で記述 Wikiからテストを実行できる 各プログラミング言語とのアダプタ 各プログラミング言語でのテストケース実装
  31. 31. BDD Kentは「常に(その時における)ユーザーの立場 でテストを実装するんだ。」といいました。 現 実には多くのTDDビギナーはそうはせず、 UnitTestに集中しすぎ、時には実装をテストし てしまうことに注力したのです。 BDDは様々な思惑があったとは言え、 現実的な 理由としてはTDDの誤解される使い方を是正する ための考え方として生まれました。
  32. 32. Scenario BDD より自然言語らしさを目指した結果、 テストコ ードと自然言語を記述するファイルを分断する という選択をした流れがあり、 それらを ScenarioBDDとよぶことがおおいです。 現在の Cucumber系がそれらにあたります。
  33. 33. Spec BDD テストコードと自然言語をできるだけ同一ファ イル内におさめながら、 可読性の向上を目指す という選択をした流れがあります。 それらを SpecBDDとよぶことがおおいです。 現在のRSpec 系がそれらにあたります。
  34. 34. STDD アジャイルの一形態であるScrumは今や世界中で 認識されている手法になりました。 Scrumは実 現すべき事に「Readyの定義」「Doneの定義」を 決めることが多いです。 実現すべき事は Product BackLog Itemとよばれ、 ユーザースト ーリーで書かれることが多いです。 このDoneの定義をユーザーストーリーを取り組 むときに、 テストとして実装してしまうことで 開発をするSTDDがうまれました。 StoryTestDrivenDevelopmentです。
  35. 35. Specification By Example 幾年かを経て、Specification By Exampleとい う概念がうまれます。 これは今迄のBDDやATDD をうまく包括するような概念として生まれまし た。 主張は「Specification By Exampleとして 書かれたテストはLive Documentなんだ」 (「例 示による仕様としてのテストは生きたドキュメ ントだ!」)ということです。
  36. 36. Agenda 自動統合テスト 誤解と効果 TDD/BDDについて 歴史 TDDの自殺 失敗するTDD
  37. 37. Domain ドメインの分け方として2分別する方法がある アプリケーションドメイン ソリューションドメイン
  38. 38. Application Domain ソフトウェアシステムの導入によって変化させ たい領域のこと。 問題ドメインと呼ばれる事が多いが、必ずしも 一致しない。
  39. 39. Application Domain 端的な例だと、要求レベルで表現できるユーザ ーが達成しようとしている内容
  40. 40. Solution Domain ソフトウェアシステムの個々の技術や組み合わ せ方。 解決ドメイン、解決領域と翻訳されることもあ る。
  41. 41. Solution Domain 個々の言語、ライブラリ、ミドルウェアなど。 実際のコードや設定やインフラなどによる実装 技術。
  42. 42. Best Production Code Application DomainとSolution Domainが同一表 現になること。 「やりたいことを書いた」=「実装した」
  43. 43. Example MDA系 一部では概念図からプロダクトコードを自動 生成することに注力している DSL系 アプリケーションドメインをそのままかける ような専用言語によってソリューションドメ インとの身時を埋める
  44. 44. Example BRMS システムのロジックの一部をデシジョンテー ブルで記述できるようにする
  45. 45. Problem 我々の世界はそこまで綺麗にコードをかける実 力もツールもない
  46. 46. TDD Solution まずテストコードに達成したい事を表現する プロダクトコードを実装する テストが通った状態で綺麗にする
  47. 47. Test Code of TDD TDDはDog Foodingである テストコードが最初のユーザー テストコードに要求を書いている テストコードにアプリケーションドメインがあ る
  48. 48. Production Code of TDD まずはある範囲で保証できるコードを書く 保証できる中で綺麗にしていく TDDの中でどうやってテストとプロダクトを綺 麗にするかは語られていない。 TDD用のリファクタリングがない
  49. 49. Best Production Code アプリケーションドメイン = ソリューションドメイン
  50. 50. TDD テストコード = アプリケーションドメイン プロダクトコード = ソリューションドメイン
  51. 51. Product Refactoring 実際にはなんらかの形でアプリケーションドメ インをプロダクトコードに入れている 命名、依存関係整理、レイヤ分割
  52. 52. Test Refactoring DRY...?
  53. 53. Domain テストコードにアプリケーションドメインが残 ってしまっている。 アプリケーションドメインが重複している。
  54. 54. Domain 重複しているだけならまだいい。 実際には違うものが表現されている。
  55. 55. Example TestDouble Integration Test
  56. 56. Domain TestDoubleもしくはIntegrationTestのsetupを 書く事で、既にある他の機能の劣化コピーもし くは完全なコピーを書く事になる。
  57. 57. Domain ツールとTDDの都合でテストコードもしくはプロ ダクトコードにあるアプリケーションドメイン を変化させてコピーしなければいけない
  58. 58. Domain そのテストを動かすために最短でセットアップ できるものを書くのは本当に正しいのかも怪し い。 何よりアプリケーションドメインが重複してい る。
  59. 59. TDD Suicide プロダクトコードからアプリケーションドメイ ンが漏れたり、埋め込まれないことがある それを促進する力がTDDにはある
  60. 60. TDD Suicide アプリケーションドメインがないプロダクトコ ードなんて何やっているかわからない死体と同 然である。 TDDは開発の理想を壊す、守るべきプロダクトコ ードを死体にしてしまう事がある。だが、それ に気づきにくい。
  61. 61. TDD Suicide レゾンデートルを自ら破壊してしまうというTDD はまさに自殺しているに等しい。 「ドメインの重複、エセドメインの生産をして プロダクトコードをダメにしてしまう」という TDDは自殺している。これをTDDの自殺という。
  62. 62. Agenda 自動統合テスト 誤解と効果 TDD/BDDについて 歴史 TDDの自殺 失敗するTDD
  63. 63. TDD TDDをして品質があがると思う人が多くいる。 一方で上がらないと思っている人がいる。 (効果のある品質特性が異なるという話では ないよ。
  64. 64. Good TDD 強制的に検査されたプロダクトしか手に入ら なくなる事によって、つまらないバグが減 る。 最低限のテスト、最低限のプロダクトのみに よって進められるサイクルによって得られる 本質に近づくための知識を取得できる。
  65. 65. Bad TDD あるコミュニティにとってTDDは成功しやすい 手法かもしれないが、失敗する場合もある。 例 AdaコンパイラはTDDを採用したが、よろしく ないTDDを行ってしまって、今までにないバ グを発生させた。
  66. 66. Why Fail TDDが難しいから? TDDでカバレッジ100%を目指したから? 自動テストの実行結果がオールグリーンのス クリーンショットをExcelにはったから? 上3つをクリアしても失敗する原因がある
  67. 67. Why Fail TDDはコードを増やすことになっている。 低スキルなプログラマーが「プロダクト」だ としても「テスト」だとしても書くのは「ひ どいコード」であることには変わりない。 でも、意味の通じないドキュメントを書いて しまうことよりはずっとマシ :-p 言い換えれば、TDDで効果があがるのは、属個 人性の排除と、意味の通じないドキュメント によって生み出されるバグ予防、確認不足の 予防
  68. 68. ご清聴ありがとうござい ました!

×