中さんのセッションの復習です！実に１ヶ月ぶり。空きすぎたorz

今までのわんくま勉強会復習。
わんくま同盟大阪勉強会#1 Vol.1
わんくま同盟大阪勉強会#1 Vol.2
わんくま同盟大阪勉強会#1 Vol.3

わんくま同盟

忘れそうなので、わんくま同盟とはなんぞや？公式ＨＰより

わんくま同盟は、コミュニティで活動している者たちの集団です。 縦の繋がりはなく、横の繋がりで成り立っています。 メンバは全員平等であり自由です。

Microsoft MVPな方々が多数参加しているコミュニティです。
つい先日私kokaも参加させていただく事となりました。

Visual Studio 2005を使ったテストのデモ

実際のデモ内容はわんくま同盟にあるPPTを参照ｗ

で、ここでは単体テストを自動化する目的、問題点などを考えたいなぁと・・・えぇすでに勉強会は前振りと化してます。すいません中さんm(_ _)m

自動化する目的・問題点

目的。それはもう「何回も実施しなくてはならないテストを確実かつ楽に行うこと」でしょう。

では「何回も実施しなくてはならないテスト」ってなんでしょう？
ここではテストスクリプトを一切変更せず実行するって条件付きとします。変更しなきゃならないと「楽」でなくなるし。
そうなるとそういったテストってそんなに無いような気がします。
共通で利用するクラス（たとえばデータベースへのアクセスを提供するクラスなど）であれば、何回も実施しなくてはならないと思います。
実際にデモ終了時にそういった提案がありました。「全てのソースについてテストを自動化する必要はないでしょう！共通ロジックだけでいいかもね。」と。
しかし「単体テスト」であるならば、そのクラスの中で完結するテストを実施すれば良いわけで、それを複数回実施する必要はそんなにないと思います。データベース周りの環境が変わった。といった理由で同じテストをする事はありますが、そんなに何回もある事ではないですし。

となるとそのクラスを実際に利用するクラスでテストを自動化したら？ってことになりますが、そうなると今度はテストスクリプトを作成する際の「コスト」に見合った効果を期待する事ができるのか？っていう疑問が出てきます。テストスクリプトを作成する量も増えるので軽視できなくなるでしょう。

VSSやCVSによるソース管理をしている場合、「エラーの無い状態でチェックインする」みたいなルールがあるなら、テストを自動化できていれば非常に楽だと思います。ただし、ソースの変更とともにテストスクリプトをメンテする手間が発生します。コーディングのやり方次第では１度作成したテストスクリプトをめったな事で変更する必要をなくす事は可能でしょうが、機能を実装する度にその機能用に追加する必要はあるでしょう。

さらにそのテストスクリプトの動作をどのように保障するのか？って事が気になります。ソースとテストスクリプトを作成する人が同じ場合、手動でテストするのと変わりがない気がします。バグ発生の代表例である「思い込み」がテストスクリプトに入り込んだ場合、それはまったく意味を成さないものになります（TAT)
となるとソースとテストスクリプトは別の人が書く！としようとしたらPGにかかるコストが極端にいうと倍になってしまいます。。。

結論

早く上位エディション以外にも付けてくださいｗ
そしてテストを自動化するコストに見合ったものをみんなして検討しましょう！そうすればシステム構築の見積もり時にテスト工数をその分上乗せする事も可能になるでしょ！もちろんその上乗せ分システムの信頼性も向上する！という価値も付けたうえで。