TDDやりたいけど出来ない場合

開発

プロジェクト管理者が嫌がるケース

  • テストケースをコーディングしていると余分な時間がかかる
  • テスト工程が増えるだけだ（どっちにしろテストしないとダメでしょ？）
  • 教育コストかかるじゃん。そんなことしてないでさっさと作れ
    • 解決案
  • どっかからメトリクスを出して効果を説得する
  • スケジュールを変更しなくていいからとりあえずやらせてもらう
  • テスト工程が増えるのではなく、本来必要なのだという話や位置付けをartonさんの記事等を元に説明する
  • 開発者が各々の裁量でこそっとやり、既成事実を作ってしまう（土台から固める）

設計者が嫌がるケース

  • 俺がテストコードを見ても内容を理解できないから意味ない。
    • ちゃんと俺にもわかるように単体テスト仕様書で書けと言われる
  • 設計書から自動生成しろ
    • 解決案
  • そもそもコードに対するカバレッジの検証（と乱暴に言っておく）なんで理解できなければ理解しなくていいです
  • 設計者は設計者の責任においてテストを実施し設計・仕様に対する検証して下さい
  • 設計書が自然言語で書かれている限り自動生成は無理
    • （形式的なもので書いてくれるのであれば別という話で）
  • 設計に対するフィードバックは迅速に行えるはず

プログラマが嫌がるケース

  • やり方わからん。めんどくさい。何でそんなことしないとダメなんだ
  • 新しいこと覚えるの大変そう
    • 解決案
  • 以下について常識的な時間内で定量的に測定出来るような説明をしていただければ、あなたの言うとおりにしようと思いますので示してください。という。
    • 何を持ってコーディングが終わったと言うのか？
    • あなたの単体テスト仕様書は何を保証しているのか？
    • 実施した変更が他の箇所に影響を与えないと保証する方法は？
    • 何度も行っているテスト（回帰テスト）が毎回正しいと言える根拠は？
  • やり方がわからない人間には周りが教えてあげる
  • 周りで楽しそうに実施して寂しがらせる