TddAntiPatterns - TDD のアンチパターン
TddAntiPatterns - TDD のアンチパターン 目次 この文書について TDD のアンチパターン TDD アンチパターン・カタログ 嘘つき。 (The Liar) セットアップ過多 (Excessive Setup) 巨人 (The Giant) モック酔い (The Mockery) 検査官 (The Inspector) 太っ腹な残り物 (Generous Leftovers) 地元の英雄 (Local Hero) 小姑 (The Nitpicker) 秘密のキャッチ (The Secret Catcher) ペテン師 (The Dodger) 大声 (The Loudmouth) はらぺこキャッチ (The Greedy Catcher) 序列屋 (The Sequencer) 隠れ依存 (Hidden Dependency) 点呼 (The Enumerator)
テスト駆動開発やユニットテストを定着させるには
ユニットテストやテスト駆動開発(TDD; Test Driven Development)については、メリットや作り方の説明ばかりが先行している気がします。 現場にとって本当に必要なのは、どうやったら開発の現場に定着させることができるのかということではないでしょうか。 カバレッジだとか、より効果的なテストコードだとかは、ユニットテストが継続的に実施されるようになってからのハナシだと思います。 私が実際に、開発現場にユニットテストとテスト駆動開発を導入した経験から、この問題を考えてみたいと思います。コンテンツ障壁ユニットテストしたくなる環境オススメ障壁 まず、最初に意識しておいていただきたいのは、テスト駆動開発を導入する際に、障壁となるのは誰かということです。 テスト駆動開発の導入をもっともシブるのは、経営者でもマネージャでもありません。 技術者です。 普通、技術者(に限らないとは思いますが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
