忍者式テストはXPに追加するプラクティスのひとつ。
2001年ごろから*1実践していたプラクティスに、2004年に名前をつけた。 *2
考え方
TDDは素晴らしそうだ。それはプログラミングのレベルだけでなく、あらゆるレベルでも素晴らしいかもしれない！ ユーザーが製品を使用する視点のテストであっても、テストによって守られたり、テストを考えることで良い仕様を発見していくのではないか！！
どうやるの？
各ストーリーにそれがうまく動いていくることを確かめるテストケースやその際の注目点を書いておいて、それをもとに製品を触る。 これまで作ってきた全てのストーリーをおさらいし、今日の製品でもうまく動いていることを、毎日確かめる。
テストケースの準備ができてないなら、ストーリーをおさらいしながら「どんなことを試したらこのストーリーがうまくできているだろうか？このストーリーはほんとうに素晴らしいのか？」を考えて製品を触れば良い。 ついでにテストケースも書ける。
UnitTestあるよね？
自動でいいようなことは計算機に任せ、空いた時間で製品を触ろう。
毎日？全部？手で？
毎日、全部、手で。
毎日ストーリー増えるよ？
そう！今日全部確かめることができたのなら、ちょっと増えたって明日も確かめることができるよ！
この様子が忍者のジャンプの訓練を連想させたため、「忍者式テスト」となった。
「毎日」の考え方を変えて量に適応
量が増えすぎたときには、頻度をちょっと工夫するとよい。
毎日一回テストをする、ということは、一度やったテストは24時間やらない、と言い換えることができる。 最後にテストしてから24時間以上経ったテストケースだけを集めたリストが、いまから確かめたいテストケースといえる。
「最後のテストからN時間非表示にする」というのが頻度の調整のアイデアの大元である。
各テストケースごとに非表示にする期間を設定するのはどうだろうか。 直近の成績や開発状況から、このNを計算することで、製品の弱い・脆い部分、実装の若い部分、ユーザーの興味のある部分の頻度を高く、安定している部分の頻度を低くするといった調整が可能になる。
より詳しい議論
XPのプラクティスが相互に関係し合って効果を増すように、忍者式テストも想像しやすい効果以上の効果を生む。そう言った議論については2023年の一連の論文に詳しく述べられている。
