xUnit を導入する積極的な理由をメモ書き。
Windows アプリケーションでは NUnit を使える構造設計を
http://www.moonmile.net/blog/archives/2054
導入できるかどうかは上記のポイントがありますが、さて、xUnit を導入する積極的な理由はどこにあるのでしょうか？
…と言いますか、いままで何とか仕事をこなしてきたから、同じ方法でやりたいのは当然なんですよね。むやみに Change !!! もできないわけで、そこには実装者なり経営者なりのメリットが必要なわけです。
win-win な関係って奴ですね。相手に対する営業的トークも少し混じりますがｗ
■現場でのメリット
昔、Eclipse が無かったころは、Java のコーディングをするときには、vi/emacs で十分だよ、という意見が大半でした。Visual Basic 2.0 の頃は、統合開発環境というよりは、その言語に【密着した】コーディング環境というイメージが強いのです。
でも、今 Eclipse を使わずに Java のコーディングをすることは皆無…とまでは言いませんが、少ないですよね。PHP のコーディングでも、JavaScript のコーディングでも、それなりの IDE(統合開発環境)を使うのが普通になっています。
で、xUnit を使うというのは、それくらい【便利】なのです。
これは、以前、携帯電話の中身(アプリケーションじゃなくて、内部実装を C言語で)を作っていた頃なのですが、その頃 xUnit の導入は「導入コストがかかる」という意見が大半です。まぁ、この「導入コスト」については、
・xUnit を学習するための暇がプロジェクトで取れない。
・xUnit を作っても、単体テスト用の Excel シートを書くと二重に手間がかかる。
・現在、単体テストがうまくいっているから、xUnit を導入するメリットはない。
のように、学習コストが大きいことや、導入したときのメリット(現場レベルのメリット)がないことを理由に避けられます。
このパターンは、なにも xUnit の導入に限ったことではなく、
・VB6.0 のアプリを VB 2010 に移行する
・データベースの扱い方を、SQL 文を学習せずに、古い O/R マッピングを使い続ける。
・統合開発環境を導入しない
というような【新しいこと】に対する拒否反応…と言いますか、現状の慣性の法則が働くので、特に珍しいことではありません。心理的な障壁が多いのです。
いわゆる、新しいものが好きな開発者は、どんどん導入するのですが（かといって、新しいものを導入しすぎてあらぬ方向に行きかねませんが）、いわゆる大半の開発者はそのままなのです。
なので、
・新しいものを導入する前の、心理的な不安
・新しいものを導入した後の、メリット
を比較して、心理的な不安 ＜ メリット となるようにします。
「心理的な」という言葉を使っているのは、過去の業務コストやら時間やらを計算してたたき出しても、「心理的な不安」は減らないからです。このあたりは、心理学を少しかじるとわかります。
さて、心理的な不安を低くする方策としては、
・学習コストが、【思ったよりも】低いことを強調する。
→ 数時間の xUnit の学習だけで済む。
→ 基本は、Assert.AreEquals だけ。
→ テストの基本パターンをあらかじめ用意する。
・単体テストの Excel 試験仕様書の記述が軽くなることを強調する。
→ 二度手間はやらない。
→ ざっと分類書くだけにする。
→ 単体テスト自体は、コードや、それに書かれたコメントで十分
を強調します。
・現在の単体テストがうまくいっているから
の理由のほうは、放置しておきます。
# そういう場合は、放置しておいたほうが「うまくいく」し、
# 逆にうまくいかない場合は、「関わらない」ほうが無難です。
# やむを得ず、関わらなければいけない場合は、トップダウンで適用します。
導入後のメリットのほうは、
・再帰試験がやりやすくなる。
→ 実際に xUnit のコードを実プロジェクト用に書いて、動かすとよいでしょう。
・複雑なロジックの完成が非常に早くなる。
→ いままで1日かかっていたコーディングが1時間で終わることも稀ではありません。
→ 慣れてくると適当なテストコードを書いても、それなりにロジックが作れるのです。
を強調し、実践します。実際に動かしてみないとメリットは分かりづらいですからね。
MVC パターンを適用していれば、他人が書いたコードに対して、xUnit を導入することもできます。
このあたり、もっと慣れてくれば、詳細設計書自体を半減させることも可能です。
■経営サイドのメリット
技術的なことは分からないけど、お金のこと（コストのこと）が気になるマネージャや経営者への説明は、技術者への説明とは違って「コストが下がる」「儲かる」ことを強調します。
まぁ、それが「経営」ってものですから。
・xUnit を導入すると、次回のプロジェクトで、単体試験のコストが半減します。
・xUnit を導入すると、プログラマを 2 割減らしても大丈夫です。
・xUnit を導入すると、詳細設計から結合設計までの期間を 2 割減らしても大丈夫です。
・xUnit を導入すると、顧客からの要求を取り入れやすくなります。
・xUnit を導入すると、不具合が半減して、品質が非常によくなります。
多少「売り」文句が入っていますが、真面目に導入するとこのくらいの削減ができます。
実は、削減≒プログラマの削減になるので、開発者にとっては痛し痒しなわけですが、他社にとっての競争力になることは確かです。「品質」がよく、「早期納入」が可能になります。
# CCPM と合わせると、「納期遅延」にも対応が可能です。
xUnit は Visual Stuido などの製品とは違って、購入コストは 0 ですから(大抵は無償で配布されています)、スタートアップでコスト的に躓くことはありません。
～
XP や TDD を導入すれば更に加速がつきますが、最初は xUnit の導入だけで十分です。xUnit を導入するときの【文化】として適切でない場合もあるので、そのときは従来の開発スタイルに戻すのも良いです。
適合不適合は、どこにもあるもので、それぞれの文化にあわなければ導入を見合わせたほうがよいでしょう。
