テスト駆動開発における進化的設計とデザインパターンの勘所とは？〜テスト駆動開発をやめて、なお残すべき習慣とは(9)
前回から、書籍を辿り、TDDの再考を試みています。TDDを既に知っている、実践しているという人にとっては、TDDについて新しい発見、ジャメヴ（未視感）が起きれば幸いです。たとえTDDが不要だったとしても、不要だと判断したものが一体何だったのか知ることは欠かせません。 忘れないで、テスト駆動開発にもデザインパターンの話が出てくるよTDDはテストファーストやベイビーステップのインパクトがありすぎて、あまり目立っていないですが、書籍『テスト駆動開発』にもソフトウェアパターンの話が出てきます。そう、出てくるんですよ。 余談ですが、テスト駆動開発３部におけるSingletonパターンの説明はGoFの説明とは違ったユニークな内容になっています。（本で確認してみてね） 1回だけ設計ではなく繰り返し設計注意点ですが、テスト駆動開発においてのソフトウェアパターンは、プロジェクト初期に１回だけパターンを使って
マニアが潰したテスト駆動開発〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （５）
昨年１２月に行われた和田卓人氏と『時を超えたプログラミングの道』編集長／『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の記事第5弾をお届けします。 対談のこれまでの記事は以下になります。
ヘロヘロスクラム、内部の質、変化のための設計〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （３）
ヘロヘロスクラムを見かける話懸田：さて、次の話題がたぶんテーマの根幹だと思うんですけど、そこらへん少しお願いします。 和田：ブログエントリーで一個ずつタイトル並べたみたいな感じですね。じゃあトピック「スクラムは広まったがコードや設計がダメだとエンジニアは生き生きしないのではないか？」。 家永：これはいわゆるファウラーの所のヘロヘロスクラムとかっていうキーワードですね。 和田：角さんが訳したやつ。 家永：和訳があるので、知られてはいるんだけれども、実際僕がアジャイルコーチというポジションで入ると、期待されるところの最初はまずはプロセス面を見るというところがあって、コードまで見るという機会が逆に離れてしまっている。プロセス部分にもまずフォーカスが当たるんだけれども、実際にもう一歩踏み込んでコードを見てみると、「これ大丈夫か！？」とドキッとする機会が何度もある。例えば、僕は（Ruby on）Ra
フィードバックをイチから学び直す〜テスト駆動開発をやめて、なお残すべき習慣とは(4)
前回、テストの４象限を紹介しました。今回からフィードバックについては、複数に分けて解説します。1回目は、フィードバックの基本のキから解説します。次回に実戦テスト駆動を参考に多重のフィードバックを解説する予定です。 フィードバックのおさらい”フィードバック”という言葉は、意味が多義的に使われており、誤解を生じやすいです。Wikipediaのフィードバックを下記に引用します。 フィードバック（feedback）とは、もともと「帰還」と訳され、ある系の出力（結果）を入力（原因）側に戻す操作のこと。古くは調速機（ガバナ）の仕組み[1]が、意識的な利用は1927年のw:Harold Stephen Blackによる負帰還増幅回路の発明に始まり、サイバネティックスによって広められた。https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A3%E3%83%BC%E3
スタブ・モックは本当に悪者なのか？〜テスト駆動開発をやめて、なお残すべき習慣とは (2)
技術詳細は外側へ寄せるポイントは、中心となる対象ドメインは何か？中心から排除したい要素は何か？を考慮して区分けすることです。中心のドメインから排除したい項目の代表例が、データベースアクセスや外部Webシステムやメッセージングといった詳細の技術要素です。ドメイン駆動設計の設計判断を取り入れている場合は、オブジェクトへのアクセスするためのRepositoryのインタフェースのみを中心ドメインに入れ込み、Repositoryの実装（特定のデータベース種類やSQLなど実装詳細）は外側に追いやります。同様に、インタフェースのみを中心にいれてメッセージングや他のWebシステムのアクセス等の実装の詳細は外部に追いやります。 うまく区分けできれば、中央に残った純粋なビジネスについてのルールや状態遷移についてをユニットテストやリファクタリングを継続することができます。リファクタリングによる設計改善を継続する
あなたのテストの盲点はどこにある？〜テスト駆動開発をやめて、なお残すべき習慣とは(3)
http://studiototoro.com/musukarakka-471より改変前回、スタブ・モックの使いどころの再考について触れました。そのなかで、ユニットテストのみに頼るのは、盲点が生まれるという点を指摘しました。「群盲象を評す」という寓話があります。各々の盲目の人が象の一部を触って象を語るだけでは部分でしかありませんし、盲点も消えません。 象の部分を統合して初めて全体を語れるように、一つの視点では盲点ができてしまいますが、複数の視点があればそれを防ぐことができます。 今回は、アジャイルテストの４象限を使って、テスト観点の全体像をお伝えし、次回では多重のフィードバックループについて盲点を少なくする仕組みについて解説します。 テスト駆動開発のスタイルをやめたとしても、自分たちが作り続けているプロダクトが期待通り動き続け、プロダクトがユーザや市場によりフィットしていくようにするには、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
俺達のTDDの戦いはこれからだ！〜テスト駆動開発をやめて、なお残すべき習慣とは(1)