単体テスト≠ユニットテストなんだという事
近年のソフトウェア開発では単体テストの自動化が当たり前になってきています。
「いや、とっくに当たり前だよ!」というお言葉も多いと思いますが、現実的にまだまだ取り入れていない企業も多いのです。現に僕自身も取り入れていなかった1人な訳でして。
簡単そうな問題なのですが、意外と商慣習的な問題が根強く絡んでいる気がしてなりません。
ソレは納品資料になるの?
ソフトウェアを納品する際には納品物としてソフトウェアの他に分厚〜い資料を渡します。その資料の中に単体テスト仕様書兼報告書といった資料がある場合があります。もしかすると単体テストは社内だけで留めておいて、その後の結合テストや総合テストから収めているというケースもあります。今回は単体テスト仕様書も納品物として収めているケースとして予めご理解ください。
さて、資料に報告書と冠しているのは『キチンとテストしてますよ!』という証拠を提示する為です。じゃあ、コードで書いた単体テストが報告書になるのか?と言うとなりません。
「ふーん、コードで書くのはいいけれど、ソレはキチンとした納品資料になるの?」
という問いとともに、「テストコードは書いてもいいけれども、納品資料は別で準備しなさい」と門前払いの如く却下されました。
『おいおい、コードでテストも書いて納品資料も別に書くのか、二重の手間じゃないか。。。よし、コードはいいや。どうせ、紙の資料は必ず作らないといけないんだし』という思考回路です。
この辺りも色々方法はあるのですが、当時は何も分かっておらず簡単にサジを投げてしまいました。
そもそもの目的が違う。という事に気付いた
自分の中で単体テストは、ほとんど誰も読まない大変面倒な資料を大量に作って証拠を揃えるという行為でした。もちろん、テストは行うので品質保証には欠かせないと思います。ただ、出番は開発工程の後半の位置付けです。
当然、テスト管理をしっかりされていて、ソフトウェア開発開始時に既に紙の単体テスト仕様書が存在している現場もある事でしょう。残念ながらそんな現場に係わった事はありません。。。なので、僕自身が単体テストで連想するのは偏っていますが上記の通りです。
ユニットテストは現在開発中の機能を作成する段階から使用していきます。テストを少し書いて、それをパスするコードを書いて、またテストを足して・・・を繰り返すのです。
例えば、何か単純なメソッドを作成したとして、それを試すには画面を動かすなり何なりしないといけません。でもテストユニットを作っておけば、画面側とは切り離してスグに動作を確認する事ができます。要は開発のお手伝いをしてくれるナイスな存在だったんです。
単体テストであって単体テストではない
僕自身もそうですが、間違ったイメージで捉えた結果、紙のテスト仕様書と同じ事を求めてしまったり、良く分からないからやらなくていいやと導入をやめてしまうんじゃないでしょうか。
紙の単体テストの呪縛が強かった様です。
まとめ
今まで何度かユニットテストを行おうとして挫折してきましたが、そもそもの紙の単体テスト仕様書とは何なんだ?というのを見つめなおした結果、腑に落ちた感じがしました。
ウォーターフォールでゴリゴリとWindowsForm系を開発していた人ほど、この考え方に染まっているんじゃないかなぁ・・・と思っていたりします。
もし、同じように思っていた人の助けになれれば幸いです。
ありがとうございました。