likeatdd.md

用意するもの

• 課題
• 問題（不具合）
• Wikiやメモ（オープンなものがいい）

準備

• 現在の動作をユーザー視点で手順として、書きだす
  • Q&A方式で書くと書きやすい
  • 複数のパスがあるなら、思いつく分だけ、書きだす
• 未来の動作をユーザー視点で書きだす
  • 同様にQ&A方式で書く

実装

手順/計画を書く

• 15分から30分単位ぐらいの作業に分割する
• 実装する作戦
• どこからか書くか、どんな順番でつくっていくか

実装計画に従って、実装する

• 一つ終えたら、準備で書いた手順(テスト)をする、現在、未来のもの
• 未来の手順でたりないことがあれば、手順(テスト)を更新する
• ある単位の実装計画が終わったらコミットして、次の実装計画を立てる
• 完成するまで繰り返す

次の人へ

レビューア向け（テスター向け）

• 出来上がった手順(テスト)で試験（チェック）ができる
• 変更前の手順（テスト）を確認して、実装の価値を確認することができる
  • これこそがやりたかったことかどうかを確認する
• この手順を足掛かりにして、探索テストができる

実装者向け

• 修正する前に確認する手順（テスト）になる
• 仕様を理解する手助けになる

効果

• 迷子にならない
• 何度も仕様を確認、反芻できる（ほんとうにこれでいいかを確認できる）
• 早くテストを動かしたいから、実装する単位を短くする方向にうごく
• 自然とテストケースを考えるようになる
• 回帰試験に使えるドキュメントが手に入る

まとめ

• TDDっぽいことと、忍者式テストが混じっている
• 一人でもできる。複数人でもできる
• 脳みそでやっていることを整理しながらできる
• 安い？早い？