TDDの自殺 #TDDeX

5,742 views

Published on

2013/07/28 に開催したTDDeXchange の発表スライドです。

TDDの自殺 #TDDeX

  1. 1. kyon_mm 2013.07.28 TDDeXchange TDDの自殺 TDDとドメインと仕様と
  2. 2. Self Introduction きょん(@kyon_mm) テストエンジニア Groovy, C#, F#, Scala SCMBootCamp, Nagoya.Testing, CDStudy, 基礎 勉強会, Cafe.Testing, STAR
  3. 3. Agenda TDDの概要 ドメイン 理想のコード TDDとドメイン まとめ
  4. 4. TDD概要
  5. 5. Definition of TDD TDDとはソフトウェア開発者向けフレームワー クである。 RED, GREEN, REFACTORというアクティビティ のスパイラルモデルが根幹にある。
  6. 6. What kind of FW TDDは次の2点を支援するフレームワーク 「開発者の意図を確認すること」 「開発者が心地よいコードを書き始める事」
  7. 7. TDD Foundation 客観的で頻繁にも実施できる検査群 確認し易い検査結果群 RED,GREEN,REFACTORのライフサイクル
  8. 8. Agenda TDDの概要 ドメイン 理想のコード TDDとドメイン まとめ
  9. 9. ドメイン
  10. 10. Domain ドメインの分け方として2分別する方法がある アプリケーションドメイン ソリューションドメイン
  11. 11. Application Domain ソフトウェアシステムの導入によって変化させた い領域のこと。 問題ドメインと呼ばれる事が多いが、必ずしも 一致しない。
  12. 12. Application Domain 端的な例だと、要求レベルで表現できるユーザ ーが達成しようとしている内容
  13. 13. Solution Domain ソフトウェアシステムの個々の技術や組み合わ せ方。 解決ドメイン、解決領域と翻訳されることもあ る。
  14. 14. Solution Domain 個々の言語、ライブラリ、ミドルウェアなど。 実際のコードや設定やインフラなどによる実装 技術。
  15. 15. Agenda TDDの概要 ドメイン 理想のコード TDDとドメイン まとめ
  16. 16. 理想のコード
  17. 17. Best Production Code Application DomainとSolution Domainが同一表 現になること。 「やりたいことを書いた」=「実装した」
  18. 18. Example MDA系 一部では概念図からプロダクトコードを自動生 成することに注力している DSL系 アプリケーションドメインをそのままかけるよ うな専用言語によってソリューションドメイン
  19. 19. Example BRMS システムのロジックの一部をデシジョンテーブ ルで記述できるようにする
  20. 20. Domain Specific Language 小休止
  21. 21. Real Production Code アプリケーションドメインの記述のみで全ての ソリューションドメインを記述する事はできて いない。 DDDはこの2ドメイン間を橋渡しするための方法 論
  22. 22. Domain Specific Language DSLを2分別する方法がある External DSL Internal DSL
  23. 23. ExternalDSL /Internal DSL ExternalDSL(外部DSL) 一つの言語として確立されているもの SQL/XML/Regular Expression/Puppet
  24. 24. Internal DSL InternalDSL(内部DSL/Embedded DSL) ある言語の拡張として作られた言語 フレームワーク/Gradle/Chef
  25. 25. Agenda TDDの概要 ドメイン 理想のコード TDDとドメイン まとめ
  26. 26. TDDとドメイン
  27. 27. Problem 我々の世界はそこまで綺麗にコードをかける実 力もツールもない
  28. 28. TDD Solution まずテストコードに達成したい事を表現する プロダクトコードを実装する テストが通った状態で綺麗にする
  29. 29. Test Code of TDD TDDはDog Foodingである テストコードが最初のユーザー テストコードに要求を書いている テストコードにアプリケーションドメインがあ る
  30. 30. Production Code of TDD まずはある範囲で保証できるコードを書く 保証できる中で綺麗にしていく TDDの中でどうやってテストとプロダクトを綺 麗にするかは語られていない。 TDD用のリファクタリングがない
  31. 31. Best Production Code アプリケーションドメイン = ソリューションドメイン
  32. 32. TDD テストコード = アプリケーションドメイン プロダクトコード = ソリューションドメイン
  33. 33. Product Refactoring 実際にはなんらかの形でアプリケーションドメ インをプロダクトコードに入れている 命名、依存関係整理、レイヤ分割
  34. 34. Test Refactoring DRY...?
  35. 35. Domain テストコードにアプリケーションドメインが残 ってしまっている。 アプリケーションドメインが重複している。
  36. 36. Domain 重複しているだけならまだいい。 実際には違うものが表現されている。
  37. 37. Example TestDouble Integration Test
  38. 38. Domain TestDoubleもしくはIntegrationTestのsetupを書 く事で、既にある他の機能の劣化コピーもしく は完全なコピーを書く事になる。
  39. 39. Domain ツールとTDDの都合でテストコードもしくはプ ロダクトコードにあるアプリケーションドメイ ンを変化させてコピーしなければいけない
  40. 40. Domain そのテストを動かすために最短でセットアップ できるものを書くのは本当に正しいのかも怪し い。 何よりアプリケーションドメインが重複してい る。
  41. 41. TDD Suicide プロダクトコードからアプリケーションドメイ ンが漏れたり、埋め込まれないことがある それを促進する力がTDDにはある
  42. 42. TDD Suicide アプリケーションドメインがないプロダクトコ ードなんて何やっているかわからない死体と同 然である。 TDDは開発の理想を壊す、守るべきプロダクト コードを死体にしてしまう事がある。だが、そ れに気づきにくい。
  43. 43. TDD Suicide レゾンデートルを自ら破壊してしまうという TDDはまさに自殺しているに等しい。 「ドメインの重複、エセドメインの生産をしてプ ロダクトコードをダメにしてしまう」という TDDは自殺している。これをTDDの自殺とい う。

×