スタブ・モックは本当に悪者なのか？〜テスト駆動開発をやめて、なお残すべき習慣とは (2)

技術詳細は外側へ寄せるポイントは、中心となる対象ドメインは何か？中心から排除したい要素は何か？を考慮して区分けすることです。中心のドメインから排除したい項目の代表例が、データベースアクセスや外部Webシステムやメッセージングといった詳細の技術要素です。ドメイン駆動設計の設計判断を取り入れている場合は、オブジェクトへのアクセスするためのRepositoryのインタフェースのみを中心ドメインに入れ込み、Repositoryの実装（特定のデータベース種類やSQLなど実装詳細）は外側に追いやります。同様に、インタフェースのみを中心にいれてメッセージングや他のWebシステムのアクセス等の実装の詳細は外部に追いやります。 うまく区分けできれば、中央に残った純粋なビジネスについてのルールや状態遷移についてをユニットテストやリファクタリングを継続することができます。リファクタリングによる設計改善を継続する

[ten-gallon-Mouse]

“初期に知りたい、プロダクトが市場にフィットするかの判断の情報はユニットテストでは提供してくれません。プロダクトコードについて私達が知らないことがいったい何で、何をすれば知識を獲得できるのかを自分たち

[nagao198X]

“中央も周辺も複雑でなく必要ないと判断するならトランザクションスクリプトでビジネスロジックと周辺環境（例えばデータベース）を一体に書いて纏めてテストする作戦のほうが手っ取り早いでしょう”

[kakeda]

ヘキサゴナルアーキテクチャーとスタブ／モックの使い方

[kompiro]

ダブルはインターフェースが安定していないと。railsの開発やフレームワークのドッグフーディングではスタブやモックの使い所ではないと思うのでDHHの指摘は実は的外れなきがする。(呑んでます)