TDD
#テスト
from: 単体テストの考え方/使い方#644210b58660300000877940
色々書いてたらコネクティングドットしたkoushisa.icon
TDDの意義
自然と責務分割とインタフェース設計に意識が向く
自己完結するフィードバックで設計をインクリメンタルに改善できる
ビジネス要求に答えるうちにアーキテクチャの変化のフィードバックループの起点となる
1. テストケースを考えたい
2. 取りうる状態ごとに対して望ましい振る舞いをケースに起こす
3. テストケースに起こすためにビジネス要求の問題空間から取りうる状態を洗い出す
4. ビジネスとそれ以外を分けるDDDっぽいレイヤードアーキテクチャになる
5. CRUD以外のビジネス要求に対しアーキテクチャがスケールしなくなる
6. State-Action-Model (SAM)パターンでモデリングしはじめる #フロントエンドでMV*フレームワークを使わない理由
7. ビジネス要求のモデリングとメンタルモデルを一致させようとドメインイベント（Domain Event ）を用いる
8. CQRSに近い構成になる
9. ビジネス要求をそのままアーキテクチャに反映させる準備が整う
10. ループ
ホワイトボックステストが必要な場合は可能な限りFinite State Machine(FSM)とかModel-based testingに落とし込む
テストラスト開発