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