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