ちょっとメモ的に書き下し
CppUnit やら NUnit やらは、10年前から使っているのですが、これらの単体テストをうまく活用するためにはコツが入ります。と、言うか、うまく活用できるようなプログラミングスタイル、構造設計、進捗管理状態、になっていないとうまく活用できません。
これ、経験上ですが、NUnit を導入するときの技術的な問題(NUnitを知っているとか知らないとか、Assert.AreEqual だとかなんとか)よりも障壁が大きかったりします。
いくつか導入時のときに注意するポイントを上げると、
■構造設計が無理なパターン
まず、xUnit 自体、UI を必要としない設計にしないとうまく動きません。例えば、Windows アプリケーションでのボタンクリックのエミュレート、Web サイトでのリストボックスの選択、なんていうのが内部ロジックとべったりくっ付いていると、それだけでうまく活用できません。かつて、Visual Test というテストツールがあったのですが、そこまでやらないとうまく行かないという状態でして、このような手間/お金を掛けるのであれば、構造設計の段階で、単体テストがうまく機能するようにデザインする、という手間が必須になってきます。
必然的に、MVC パターン、少なくとも View の分離をしないと、ロジック部分だけをテストする、ということはできないわけです。
このあたり、プロジェクトの作業コストや設計/実装のスキル具合によるので、難しいところもあり、xUnit がうまく導入できないのは、この構造設計の段階で失敗しているというのが非常に大きいです。
■進捗管理で単体試験の項目を管理したいパターン
アジャイル開発で大雑把に管理していれば問題ないののですが、従来のウォーターフォール開発の場合は、どうしてもコーディング(PG) 単体試験(PT)の進捗を別々に管理したくなります。というか、工程的に PG と PT は別ものだから、項目を上げて進捗率を出すとか、PT 工程は PG の後でないと駄目、なんていうのが必須だったりします。
ご存じのように xUnit の場合は、コーディングとテストが一体になったときに初めて効率的になります。勿論、コーディングを全て終わった段階で、テストコードを書くという分離の方法もできるのですが、大抵は面倒くさくなって Excel シートでの単体試験管理に戻ってしまいます。
xUnit の最大の利点は、再帰テストが非常に簡単にでき、それが自動化されることにありますから、PG と PT が混在となるのが必須になります。なので、これを分離しようとすると、そもそも xUnit の利点を排除してしまうことになり、導入に失敗します。
■プログラミングスタイルの統一
これは構造設計にもあてはまるのですが、ひとりで xUnit を導入しているときは、テストする/テスト省略の境界が分かり易いのですが(そう、テストを省略できるというのも xUnit のメリットのひとつです)、複数名のプロジェクトとなると、何をテストするのか、何をテストしないのかの基準が曖昧になります。スクラムなどのアジャイル開発の場合は、たいてい、コーディングスキルの高い人たちが集まるので、それでも大丈夫なんでしょうが、ウォーターフォール開発に場合はスキルがばらばらな場合が多いので、境界があいまいだと、全体の品質が落ちます(人によって品質がばらばらになるという意味で)。
なので、構造設計をした後、クラス分けをした後に、どのロジックはテストで重視するのか、ほとんどのコンストラクタはテストを省略して良いのか、などを分離させる必要があります。
このあたりは、主にウォーターフォール開発のノウハウになります。標準的なスキルを如何に、標準的なスピードに落とし込めるのか、がウォーターフォール開発の要になるので、できる限りクラスの役割を平準化させます。加えて、標準的に活用するライブラリを準備します。
個人的に、インテル方式と呼んでいます。
逆にアジャイル開発の場合は、ライブラリはリファクタリングでできるので、標準化のプロセスはあまりありません。と言いますか、経験者が集まることが多いので、手間がかからずに自然と標準化されます(逆に、そうならなければ、アジャイル開発自体が失敗しているとも言えます）。
～
で、念のために書いておきますが、今回お手伝いをしているプロジェクトでは、この要点を確実に抑えて頂きました。なので、多分大丈夫。このあたりマネジメントの極意なんですけど、落とし穴を避ければ、成功するという鉄則ですね。リスク管理という意味で。
