ボウリングでストライクを取得した場合のテストケースを考える

プロジェクト管理

技術解説

連載 :

初学者のためのTDD（テスト駆動開発）入門

2014年11月19日(水)

吉谷愛

図2: ボウリングの点数（クリックで拡大）

[古谷] えーと、ストライク直後の２投球分の得点が、ボーナスとして加算される、で大丈夫ですか？
[高梨] そのとおりです。ですから

第1投目：10ピン倒す（ストライク）
第2投目：3ピン倒す　
第3投目：3ピン倒す
第4投目：1ピン倒す
残り15投：全てガタ—

[高梨] この場合、(10+3+3)+3+3+1=23になるはずです。
[古谷] あれ？　投球数が19投分しかないようですが？
[高梨] ストライクが出たら、そのフレームの2投目がなくなりますから、ストライクが増えれば増えるほど、投球数が少なくなりますよ。
[古谷] そうか、ストライクが多くなればなるほど投球数が少なくなりますね。だからボウリングが上手な人は、2ゲーム目になっても3ゲーム目になっても元気なのですね。
[高梨] そうですね。古谷さんもボウリングが上手になれるといいですね。それでは今まで同様、まずはテストコードの追記からはじめましょう。
[古谷] は、はい！　では、これでどうでしょう？

図3: ストライクの計算方法を考える（クリックで拡大）

[高梨] 大丈夫です。では、ここからまた一緒に考えていきましょう。考え方のフレームワークは、スペアの時と同じです。それでは前回同様、目の前の問題を起こしている原因を、「設計でストライクを考慮していない」以外で考えてみてください。

図4: 設計の変更方針を考える

[古谷] ストライクが計算できない原因は……。えーと、ストライクのルールって「ストライク直後の2投球分の得点が、ボーナスとして加算される」ですよね？
[高梨] はい。
[古谷] まずこのプログラムでは、ストライクの判断ができていません。それから、ストライク直後の2投球分の得点がボーナスとして加算されるようなロジックもないから、エラーになっているのだと思います。
[高梨] 正解です！　それではこの調子で、次の段階である「この問題の回避策」の検討へと進みましょう。さあ、どうやってこの問題を回避しますか？
[古谷] そうなると、スペアの時みたいに、ストライクフラグをつくって、ストライク直後の投球時にフラグをリセットする手は使えないですね。その次の投球分もストライクボーナスの対象になるわけですから。
[高梨] そうなります。
[古谷] それなら……　ストライクフラグと「ボーナス数を管理するボーナスカウント変数」を用意するのはどうでしょうか？
[高梨] ボーナスカウント変数とは、どのようなものですか？
[古谷] えっと、ストライクの時点で「2」をセットして、その後の投球のたびに1、0とデクリメントしていく変数です。
[高梨] なるほど。であれば、ストライクフラグは必要ないのでは？　ボーナスカウントの値を見てゼロ以外の時は、その投球をボーナス対象にすればいいわけですから。
[古谷] うっ、た、確かに……。
[高梨] 大丈夫ですよ。古谷さんは、ここまでほぼ自力で「目の前の問題を引き起こしている原因」と、「その回避策」を考え付いています。私は、そのお手伝いを少ししているだけです。それでは、次の段階である「変更する際の手順」も、古谷さんが考えてみてください。
[古谷] はい！　先ほど高梨先輩にいただいたアドバイス通り、ストライクフラグは使わずにやってみます。こんな感じでどうでしょう？

＠strike_bonus_count変数を定義。初期値はゼロ。
def record_shot(pins)メソッド内のスペアチェックの直後に下記ロジックを追加
(ア)＠strike_bonus_countの値が1以上だったら@scoreに倒したピン数を追加して、＠strike_bonus_countの値を-1する。
(イ)倒したピン数が10だったら、@strike_bonus_countに2をセット

[高梨] なるほど。倒したピン数が10だった時の@strike_bonus_countへの2のセットは、@strike_bonus_countをマイナスした後に行うわけですね？
[古谷] だって @strike_bonus_countへの2のセットが先になると、@scoreにストライクの10点も追加されてしまうので、ボーナスあげすぎになってしまいますから。
[高梨] 素晴らしい！　それではやってみてください。
[古谷] はい、ではやってみます！

図5: 残ボーナス回数という概念を考えてストライクの計算を実装（クリックで拡大）

[古谷] できました！
[高梨] 素晴らしいです！
[古谷] なんかコツがつかめかけてきた気がします！　次は連続で……
[高梨] ちょっと待ってください。そろそろリファクタリングにはいりましょう。
[古谷] えっ？　そうですか？　そんなにコードが冗長になっている感じはしないのですが……
[高梨] 行数としてはたいしたことはありませんが、TDDはリズムを大切にします。RedとGreenを繰り返したら、定期的にリファクタリングを行うように習慣づけてください。

テスト駆動開発 / TDD

著者

吉谷愛

この著者の記事一覧この著者の
記事一覧

フロイデ株式会社代表取締役

「最新のアーキテクチャを追及し続ける技術者集団」を目指す、フロイデ株式会社代表取締役社長。現在は、自身のCOBOLからRailsまでの非常に幅広い開発経験や、学生や未経験社員への技術指導経験を糧に、技術講師としてソフトウエアエンジニアの育成に注力している。2013年06月より、初心者向けの「はじめようRuby on Rails開発！」シリーズを考案。“技術者の立場にたった、技術者の心に火をつける”熱い講義をモットーとしている。