[B! testing][テスト駆動開発] cyber_snufkinのブックマーク

cyber_snufkin id:cyber_snufkin

testingとテスト駆動開発に関するcyber_snufkinのブックマーク (2)

[社内勉強会レポート] 『テスト駆動開発』読書勉強会 #8 | DevelopersIO
はじめにこんぬづは、これまでなんとなく見ていなかったんですが、ガールズアンドパンツァーを一気見した田中です。なぜでしょう、毎話目をぐしょぐしょにしながら見きってしまいました。ガルパンはいいぞ。さて本題に入っていきましょう。今回からは付録Cを読んでいきます！この会の趣旨この会の趣旨については、第一回のまとめをご覧ください。それではまとめていきます。付録C: ユニットテスト周辺の知識の整理とTDD拡張の試み概要ユニットテスト周辺の歴史や語彙を整理したり、内側と外側の回転があることについてまとめてあります。話し合われた内容 GOOSに興味が出た TDDに流派があることを知った「モックを活用すれば、(中略)設計の順番と時間を制御できることを発見しました。」とてもわかる。 ↑実装の要求レベル高いよね。設計にレイヤ構造を取り入れる考えとかが必要になるし。付録C: TDDのTは「テ
cyber_snufkin 2017/12/12
TDD

テスト駆動開発

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

テスト駆動開発

mock

testing

あとで読む
リンク
1