キックボクシングの選手 兼 指導員とITエンジニアの２足のワラジを履いたおっさんの日常を綴ったBlog

あまりにもテストコードを書かない人が多いので、ちょっとだけ。

テストコードを書くメリット

(1)「どうなれば正解なのかが明確になる」

よくテスト仕様書に「データベースの更新内容が正しいこと」という確認事項が書かれているものをみかける事がありますが、この ”正しい更新内容" とは何でしょうか？
別で、”データ仕様書” が書かれていて、その内容に沿っているかを確認する。というのであれば、まだ分からなくもないのですが、データ仕様書すら存在しない、またデータ仕様書で網羅されていないケースでそのように書かれている事が多々ありますが、何をもってOKにすれば良いのでしょうか？
テストコードが書かれていれば、処理の正解を明確に示す事ができます。
また後から見る人もテストコードから、その機能の期待する結果を知る事ができます。

(2)「回帰テストに利用できる」

自身が製造していない部品（共通部品など）を使っている処理が、関連部品の変更による影響で不具合を起こしていないか。という確認はその都度目視で行うのでしょうか？
テストコードがあれば、自分の部品の変更はもちろん、関連する部品が変更されるたびに、自分のソースが不具合を起こしていないかを容易に、また何度でも確認する事ができます。

(3)「思い切ったリファクタリングができる」

ソースコードがスパゲッティコードになっている機能があるので、共通化、スリム化をして欲しい。という依頼を受ける事がたまにあります。しかも自分が全く知らない処理のコードで、もちろんテストコードはない状態で。。恐ろしくて出来ません！！
テストコードがあれば、リファクタリングによって処理内容が壊れていないかをすぐに確認できるので、思い切ったリファクタリングが出来ます。

(4)「環境依存しない部品設計の助けになる」

部品の設計時に「この部品のテストコードが書けるか」という事が頭の片隅にでもあれば、コンテナやフレームワークに依存しない部品設計を行う助けになります。
現に、最近のWebフレームワークでは、アクションクラスまでPOJO（JAVAの場合）で書けるものが沢山あります。
------------------------

こんなに沢山のメリットがあるのに、なぜテストコードは書かれないのでしょうか？
少しだけ考えてみました。

テストコードが書かれない理由

(1)書く習慣がない、また書いた事がないので、書き方がわからない

品質やテストの旗ふりをするおっさん達がテストを書いた事がないので、当たり前のようにテストを書く事を知らない。

(2)部品がコンテナ／環境に依存し過ぎている為、書けない（と思っている）

DIコンテナって何？DjUnitって何？　という人たちがたくさん。。

(3)テストは1回すれば良いと思っている。

回帰テストの概念がない。もちろんテストの自動化なんて考えた事もない。

特に感じるのは「テストを書く事によるメリットを知らないエンジニア」が沢山いる事。
※規約などで強制されていなくても、その有用性を知っている方は書いていると思います。

先にも挙げましたが、最近のWebフレームワークでは、アクションクラスまでコンテナに依存しない形で書けるものがたくさん登場しています。流行に踊らされるのは避けたいですが、新しくても良いものは、どんどん取り入れていく姿勢が必要だと思います。
イノベーターである必要はないと思いますが、アーリーアダプターぐらいではありたいと。そこそこ新技術やIT業界の流れにも敏感な開発者。。みたいな。

最近では、便利なテスト支援ツール（JDjUnit、DBUnitなど）も利用できますので、「これは環境依存する部品だから無理」と諦めずに、テストコードを書いてみてはいかがでしょうか。