Fizz Buzz問題とTDDとテストと

Fizz Buzz問題は、プログラミング初心者向けの簡単な例題として知られています。
また、誰でもすぐにFizz Buzz問題の仕様を理解することができ、また、プログラミング結果の正誤を紛れなく判定できることから、プログラミング初心者の腕試しのみならず、TDD（テスト駆動開発）の演習として活用され、さらに、ペアプログラミングのライブ教材としても広く利用されています。

ところが、TDD等で作成されたテストコードに、【なぜその値をテストしようと思ったのか】について書かれているものを見たことはほとんどありません。

そこで、テストエンジニアの目線から、Fizz Buzz問題をテストする場合の【テストデータ】について考えてみたいと思います。

Fizz Buzz問題とは

Wikipediaの「Fizz Buss」の項によると、「Fizz Buzz（フィズ・バズ、Bizz BuzzやBuzzとも呼ばれる）は英語圏で長距離ドライブ中や飲み会の時に行われる言葉遊び」とのことです。
1からはじめ、順番に1つずつ大きな数を言って次の人にバトンタッチするだけなのですが、3の倍数のときには「Fizz」、5の倍数の時には「Buss」、3の倍数かつ5の倍数の場合「Fizz Buzz」と言わなければならず、うっかり間違えると脱落するというゲームです。

こんな感じに進みます。「1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz Buzz, 11, Fizz, 13, 14, Fizz Buzz, 16, 17, Fizz, 19, Buzz, Fizz, 22, 23, Fizz Buzz, 26, Fizz, 28, 29, Fizz Buzz, 31, 32, Fizz, 34, Buzz, Fizz, ……」

これをコンピュータがおこなうプログラムを作ろうというわけです。

コンピュータに教え込むためには仕様を厳密にする必要があります。Fizz Buzz問題の仕様には、いくつかのバリエーションがありますが、おおむね次のような記述です。

TDD

TDDとは、テスト駆動開発 （Test-Driven Development）のことです。

プログラミングのときに、対象のプログラミングが上手くできたときに合格となる【テストコード】を先に書き、そのテストに合格する必要最低限なプログラムを【開発】した後に、コードを洗練させる【リファクタリング】を行う方法です。（図1）
【テストコード】→【開発】→【リファクタリング】という短いサイクルをテンポよく繰り返す「開発方法」です（「テスト方法」ではありません）。

Fizz Buzz問題について書かれたウェブページのTDDのテストコードを見ると、多くの場合、「1のときに1」、「3のときにFizz」、「5の時にBuzz」、「15の時にFizz Buzz」となることを確認するテストを書いています。

次に、このテストが通る（合格する）プログラムをガシガシ書いて、テストが通るようになったら、書いたプログラムコードを洗練させます。洗練させる過程（リファクタリング）では、最初に書いたテストが失敗せずに通ることを確認しながら進めることで、開発者は大きなミスをしていないという安心感を持つことができます。

この「安心感を持ってテンポよく開発を進めることができる点」がTDDのメリットなのではと考えています。（といいますか、t_wada氏の受け売りです）