20.9 テストベンチのまとめ(非公式訳)
本章にはサンプルコードをいくつか示しました。その目的は、VHDLでテストベンチを作成する方法をざっと説明することにありました。こうしたテストの作成には時間と手間がかかるため、本章の最後にそのコストとメリットについて触れておくのが良いでしょう。
テストベンチを作成したことにより、検証対象モデルに隠れていたいくつかのバグが容易に見つかりました。バグが最終製品に紛れ込んだり、バグがハードウェアデバイス化されたりしてしまうと、バグを見つけてコードと対応づけるのは極めて困難です。しかしテストベンチのおかげでそうしたバグはすべて見つかりました。
テストベンチの作成には時間もかかります。本章に示したテストベンチの分量はDUVコードの1.5倍でした。実際のプロジェクトでは一般に4倍ですから、それでも相当少ない分量です。
ではテストを作成するメリットの有無についてはどうやって判断すれば良いのでしょうか。まず心にとめておいて欲しいのは、コードの記述よりもコードについて検討する作業、デバッグ作業のほうにむしろ時間がかかるということです。テストを作成すればデバッグの時間が減らせます。RTLコードと同時にテストを作成した場合はなおさらです。新たな機能を追加するたびにテストを作成すれば、コードにバグの紛れ込むチャンスはほとんどなくなります。バグが生じたときには、コード全体のわずかな部分だけを対象にバグを探せば済むという利点もあります。また、モジュールごとにテストを作成すれば、そうした複数のモジュールをシステムに統合するのに要する時間が縮まります。 システムへの統合に伴う労力を減らす最善の方法は、事前にすべてのモジュールからバグをなくしておくことです。
実際、すぐれたテストを作成したほうが、テストなしで作成したコードを修正するのよりも時間が少なくて済みます。ほとんどの開発者はこのことに気づいています。その証拠に、テストをすることに慣れた開発者のほとんどは、テストを作成しない以前のやりかたには戻らなくなります。ほとんどの開発者はいわゆる「テストに感染」します。
もうひとつ大切なことがあります。本書全体を通じて強調してきたことです。それは、優れたテストを用意しておけば、何か改善の余地を見つけたときに既存のコードを安全に変更できるということです。コードをいじるのをためらうようでは、そうした変更はできませんから、コードの質は下がります。ちょっとした改善を続けてゆくことで、コードの質が高く保てると同時に、開発者の生産性の低下が防げます。
最後にもうひとつだけ。コードのテストを作成するということは、そのコードをクライアントコードの視点で見ることができるということです。假にモジュールのテストが作成しにくいとしたら、それはおそらく、インターフェースに何か問題があって使いづらいモジュールであるということです。優れた設計を実現するための原則の多くは、テストを容易にもしてくれます。テストを作成すればそのことに気づきます。逆もまた真です。簡単にテストができないようなら、何か問題が内在しているのが普通です。設計が優れていればテストは簡単です。
―――――――――――――――――――――――――――――――――――――――――――――
OSVVMライブラリーを利用したテストベンチは飛ばしたが、これでEffective Coding with VHDL: Principles and Best Practice (The MIT Press)は一往終わり。
