忍者式テスト🥷🏻

XPと2001年から

忍者式テストとはなにか

忍者式テストはXPに追加するプラクティスのひとつ。

2001年ごろから*1実践していたプラクティスに、2004年に名前をつけた。 *2

考え方

TDDは素晴らしそうだ。それはプログラミングのレベルだけでなく、あらゆるレベルでも素晴らしいかもしれない! ユーザーが製品を使用する視点のテストであっても、テストによって守られたり、テストを考えることで良い仕様を発見していくのではないか!!

どうやるの?

各ストーリーにそれがうまく動いていくることを確かめるテストケースやその際の注目点を書いておいて、それをもとに製品を触る。 これまで作ってきた全てのストーリーをおさらいし、今日の製品でもうまく動いていることを、毎日確かめる。

テストケースの準備ができてないなら、ストーリーをおさらいしながら「どんなことを試したらこのストーリーがうまくできているだろうか?このストーリーはほんとうに素晴らしいのか?」を考えて製品を触れば良い。 ついでにテストケースも書ける。

UnitTestあるよね?

自動でいいようなことは計算機に任せ、空いた時間で製品を触ろう。

毎日?全部?手で?

毎日、全部、手で。

毎日ストーリー増えるよ?

そう!今日全部確かめることができたのなら、ちょっと増えたって明日も確かめることができるよ!

この様子が忍者のジャンプの訓練を連想させたため、「忍者式テスト」となった。

「毎日」の考え方を変えて量に適応

量が増えすぎたときには、頻度をちょっと工夫するとよい。

毎日一回テストをする、ということは、一度やったテストは24時間やらない、と言い換えることができる。 最後にテストしてから24時間以上経ったテストケースだけを集めたリストが、いまから確かめたいテストケースといえる。

「最後のテストからN時間非表示にする」というのが頻度の調整のアイデアの大元である。

各テストケースごとに非表示にする期間を設定するのはどうだろうか。 直近の成績や開発状況から、このNを計算することで、製品の弱い・脆い部分、実装の若い部分、ユーザーの興味のある部分の頻度を高く、安定している部分の頻度を低くするといった調整が可能になる。

より詳しい議論

XPのプラクティスが相互に関係し合って効果を増すように、忍者式テストも想像しやすい効果以上の効果を生む。そう言った議論については2023年の一連の論文に詳しく述べられている。

miwa719.hatenablog.com

*1:2025年の現在も

*2:JaSST'04にデマルコが登壇するという噂をきいて、JaSSTに応募したくなり、急遽名前が必要となったのだ。

Ninja tree-jumping analogy - Martin Fowler, Kent Beck

2004年から2006年ころの文通を発掘した。

Martin FowlerとBlikiのソースについてメールしたついでに、忍者式テストのコンセプトを英語で説明したところ、

I liked this Ninja tree-jumping analogy (MF)

とKent Beckにメールを転送してくれた。*1

I like it too. To begin with you have a ridiculously small pile of tests to vault. "I can jump that easily," you say. And you can. Then tomorrow the pile is a little larger but still easy. And the next day and the next. By the time the pile is a mountain you've been jumping over it so long you no longer notice what a miracle the jump is. You think that's just how you develop software. And you're right. (KB)

2006年にその後の経過と、テストケースの抽出アルゴリズムの導入、他のチームとの比較、についてもやりとりした。(すっかり忘れていた)

2006年にもらったメールから。

Thank you for the information about your progress. I understand you to be saying that your tests take too long to execute every day, so you run a subset of the tests every day. The subset is chosen partly at random, partly by how long it has been since a test has been run, and partly by how long it has been since a test has failed. I can see how this would give you good coverage and shorten the running time of the tests.

おお伝わっていそう。

I know that David Saff at MIT has been studying test-running behavior. He found that sorting the tests so the most-recently-failed tests run first results in nearly minimal time to test failure.

実感と合っている。

英語で忍者式テストの説明をするのは難しいので、Kent Beckのメールを引用して説明とする。

*1:私の拙い英語は載せないでおく。