UnitTestを積極的にやるべき理由
同業者の友人に話を聞くと、未だにUnitTestを実施していないところもあるようで、少しその友人の体が心配になったりします(´・ω・`)
”利点は理解しているけど、作業が忙しくて入れてる隙がない”って理由があるようで。
でもね、それがあなたを苦しめてる原因になるんです。(´・ω・`)
UnitTestを行うとモジュールレベルでの動作が仕様通りであることが(ある程度)保証できます。
これは広く言われているUnitTestの利点です。
UnitTestをしっかり行うことによるメリットはそれだけではありません。
例えば、既存の製品の追加対応として、新しい機能を追加したとします。
追加する機能にもよるのですが、モジュール間を跨って、広い範囲でソースコードを修正しなければならないことが多々あります。
UnitTestをしっかり実装していることによって、
- 修正前にあったもともとの機能が損なわれてい
- 修正を行ったモジュール以外に影響がないことを確認できる
UnitTestを書かないプロジェクトで、ソースコードに修正をいれこんだ場合、すべてのテストケースを再度網羅しなければなりません。
そのまま人力で動作検証を行うと相当なManPowerがかかってしまい、本来の開発に使うべき力を動作検証で使い果たしてしまいます。
自動化が可能である部分をUnitTestで自動的に検証することによって、機能変更後の動作検証にかけなければならないManPowerは相対して少なくなり、開発に十分な力を注ぐことができます。
この手の動作確認は、製品として提供しているものであれば、必ず発生するものですし、何度も必要になってくるものです。
UnitTestを実装することは、それなりのコストが掛かってしまいますが、最初のうちにしっかり作りこんでおくと後が楽です。
つまり、みんな楽になれるってことさ！(・∀・)
ただ、UnitTestも万能ではありません。
モジュールレベルのテストでは非常に有用なんですが、UIやマルチスレッドテストには向きません。
実装しようとすればできないわけではないですが、前者であれば実行環境の画面描画性能による問題や、後者であればスレッド間の同期関係が影響してうまく動かないことがあり、その部分を解消するために結構な労力がかかります。
やることと目的のトレードオフになりますが、コストより利点の方が大きければやるべきで、そうでなければやめるべきです。
…といっても、実際の開発現場において上記で上げた問題部分に一致するのはごく一部のはず。
向くもの、向かないものがあることは理解しておいて下さいな。
