テスト駆動開発を学ぶ

第12章. 試験順序

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

私の旅は常に混沌と秩序のバランスだった。

フィリップ・プティ

第11章では、Bank エンティティを導入することで、比較的大きな設計変更を行った。新しく書いたテストも、既存のテストも、この目標を達成するのに役立った。

新しいBank エンティティの特徴のひとつは、任意の通貨ペア間の為替レートを受け入れ、保存できることだ。 為替レートはハッシュマップに格納され、2つの通貨から形成されるキーの中に格納される。 その機能とは、為替レートを変更できるようにすることだ。

この機能が機能するという確信を得るための1つの方法は、（当てずっぽうだが）それを証明するテストを書くことだ。その機能がすでにある可能性が高いのに、なぜテストを書かなければならないのか？言い換えれば、すでに開発が終わっているのであれば、新しいテストは何を駆動する可能性があるのだろうか？

この質問には3つの答えがある：

1. 繰り返しになるが、新しいテストがあれば、たとえ新しいプロダクション・コードが必要なくても、この機能に対する信頼が増すだろう。

2. 新しいテストは、この機能の実行可能なドキュメントとして機能するだろう。

3. このテストによって、既存のテスト間の不注意な相互作用が露呈し、それへの対処が促されるかもしれない。

テストは、コードを文書化するための効果的な方法である。テストには意味のある名前を使うことができるし（使うべきだし）、その機能が（どのように動作するかではなく）何をするのかを詳細に記述することができるからだ。テストは、自分自身のコードの振る舞いに関する、微妙だが重要な詳細を忘れてしまったときに、自分自身を再認識する助けにさえなる。そして後述するように、新しいテストを書くことで、既存のテストの問題点を明らかにすることができる。

テストを書くことの正当性が証明されたところで、このリストにある実装されているがテストされていない可能性のある機能に目を向けてみよう：

5米ドル×2＝10米ドル

10ユーロ×2＝20ユーロ

4002 krw / 4 = 1000.5 krw

5米ドル＋10米ドル＝15米ドル

テストコードを本番コードから分離する

冗長性テストを削除する

5米ドル＋10ユーロ＝17米ドル

1 USD + 1100 KRW = 2200 KRW#.

関係する通貨に基づいて為替レートを決定する（→から）。

為替レートが指定されていない場合のエラー処理を改善する。

為替レートの実装を改善する。

為替レートの変更を許可する

為替レートの変化

まずは既存のコンバージョンのテストを修正することから始めよう。我々はすでに、2つの通貨（例えばEUR→USD）間のレートによるコンバージョンが機能することを知っている。同じ通貨ペアの異なるレートを追加することで、テストを追加する。その後のコンバージョンがこの新しい為替レートを利用することを検証する。

テストが問題なく動作すれば、グリーン・フェーズを突破したことになる。最後のフェーズでは、必要なリファクタリングに取り組む。

Go

TestConversion の最後にもう数行追加しよう。為替レートを1.3に変更し、それが有効になることを検証する。 また、その意図を反映させるために、テストの名前を変更する。これがテスト全体である：