modest violet

読者です 読者をやめる 読者になる 読者になる

modest violet

開発者としてのあれこれや、日々の雑記など

your future hasn't written yet. no one's has.
by Emmett Lathrop "Doc" Brown

単体テスト≠ユニットテストなんだという事

Dev Dev-TDD

近年のソフトウェア開発では単体テストの自動化が当たり前になってきています。

「いや、とっくに当たり前だよ!」というお言葉も多いと思いますが、現実的にまだまだ取り入れていない企業も多いのです。現に僕自身も取り入れていなかった1人な訳でして。

簡単そうな問題なのですが、意外と商慣習的な問題が根強く絡んでいる気がしてなりません。

 

 ソレは納品資料になるの?

ソフトウェアを納品する際には納品物としてソフトウェアの他に分厚〜い資料を渡します。その資料の中に単体テスト仕様書兼報告書といった資料がある場合があります。もしかすると単体テストは社内だけで留めておいて、その後の結合テストや総合テストから収めているというケースもあります。今回は単体テスト仕様書も納品物として収めているケースとして予めご理解ください。
さて、資料に報告書と冠しているのは『キチンとテストしてますよ!』という証拠を提示する為です。じゃあ、コードで書いた単体テストが報告書になるのか?と言うとなりません。
「ふーん、コードで書くのはいいけれど、ソレはキチンとした納品資料になるの?」
という問いとともに、「テストコードは書いてもいいけれども、納品資料は別で準備しなさい」と門前払いの如く却下されました。 
『おいおい、コードでテストも書いて納品資料も別に書くのか、二重の手間じゃないか。。。よし、コードはいいや。どうせ、紙の資料は必ず作らないといけないんだし』という思考回路です。
この辺りも色々方法はあるのですが、当時は何も分かっておらず簡単にサジを投げてしまいました。

そもそもの目的が違う。という事に気付いた

自分の中で単体テストは、ほとんど誰も読まない大変面倒な資料を大量に作って証拠を揃えるという行為でした。もちろん、テストは行うので品質保証には欠かせないと思います。ただ、出番は開発工程の後半の位置付けです。
当然、テスト管理をしっかりされていて、ソフトウェア開発開始時に既に紙の単体テスト仕様書が存在している現場もある事でしょう。残念ながらそんな現場に係わった事はありません。。。なので、僕自身が単体テストで連想するのは偏っていますが上記の通りです。
これに対して、ソフトウェアでコードを書いて行う単体テストをここでは意味合いを分けるために「ユニットテスト」と表記します。大きな括りでは同義語です。
ユニットテスト現在開発中の機能を作成する段階から使用していきます。テストを少し書いて、それをパスするコードを書いて、またテストを足して・・・を繰り返すのです。
例えば、何か単純なメソッドを作成したとして、それを試すには画面を動かすなり何なりしないといけません。でもテストユニットを作っておけば、画面側とは切り離してスグに動作を確認する事ができます。要は開発のお手伝いをしてくれるナイスな存在だったんです。

単体テストであって単体テストではない

ユニットテストは色々な本やWebで「単体テストという名称で紹介されています。(間違ってはないです、念の為)前述した通り、単体テストには紙の納品資料という全くの別物が存在します
この単体テストという同一の単語が使われる事により、ユニットテストを間違ったイメージで捉えてしまった人も多いと思います。
僕自身もそうですが、間違ったイメージで捉えた結果、紙のテスト仕様書と同じ事を求めてしまったり、良く分からないからやらなくていいやと導入をやめてしまうんじゃないでしょうか。
ユニットテストメソッドを作る際には作る手伝いをして、出来た後はメソッドがおかしくならない様に続けて監視してくれる存在と思えば、なるほどと思えてきました。
紙の単体テストの呪縛が強かった様です。

まとめ

今まで何度かユニットテストを行おうとして挫折してきましたが、そもそもの紙の単体テスト仕様書とは何なんだ?というのを見つめなおした結果、腑に落ちた感じがしました。

ウォーターフォールでゴリゴリとWindowsForm系を開発していた人ほど、この考え方に染まっているんじゃないかなぁ・・・と思っていたりします。

もし、同じように思っていた人の助けになれれば幸いです。

ありがとうございました。