IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→起業)

いつユニットテストを書くべきか テスト必要論vs不要論

これQiitaに書きたかったんですが
正直テスト周りは私も100%納得できていないので、一旦考えていることをメモとして吐き出してみようと思います。

 

ユニットテストとか言う分かりづらい用語

ユニットテスト単体テスト
ユニットテストは手動テストと自動テストがあります。
議題に上がる「テストを書く」は「ユニットテストの自動化」です。
若手の頃、ユニットテスト自体の是非について皆が議論しているものだと思って混乱しました。たぶん結構な人数未だに混乱してると思います。

以下面倒なので「テスト」と書きます。

テストは他のシステムと同じ

テストは銀の弾丸ではありません。
テストは、要は手動テストの自動化です。
それ以上でも、それ以下でもありません。
他のシステムと同じです。自動化したほうがメリットが有るもの、自動化するメリットの薄いもの、あるいはメリットがあるが自動化する=システム化するのにコストが高いものなどあります。

世の中のありとあらゆる物を自動化するべきという人は居ないはず・・・いえ、居ますね。ちょっとおかしい人は居ます。自動化教団の方が・・・

 

TDDなどは分けて考える

TDDやXPなど、ああいったものはテストという行為を起点にいろんな物を解決しようとする、いわば発明です。
テスト自体の効能とは全く別物なので、テストを語る際にあちらの方面の話を持ち出すべきではありません。それなら「テストいいよ」ではなく「XPいいよ」というべきです。

 

テストは何に寄与するか(メリット)

システム化・自動化なので、割と簡単です。

  • 大量に行うものを一瞬で終わらせられる
  • 毎回同じ結果を吐き出す

副作用として現れる利点

  • 仕様に対するチェック・網羅性が早い段階で確認されがちになる

 

テストを書くコスト(デメリット)

これもそんなに難しくありません。

  • テストを書く時間
  • テストを保守するための時間(書き換えコスト)

 

要は品質とスピードに影響するということですね。
ただしとにかく良くなるというわけではなく、上手く入れると良くなると言った感じです。

 

テストはいつ、どこで書くべきか

上記から自ずと分かります。

  • 手動テストだと大量に行わなければならない部分
  • 何度もテストしたい部分
  • 絶対に品質が高くなければならない部分
  • あまり書き換えない部分
  • 再利用性が高い部分
  • プロダクトのコア部分
  • 複雑なアルゴリズム

 

テストの書き換え・保守コスト

テストはあるモジュールに対して付随したものです。
なので、そのモジュールに対して変更が入る時はテストにも変更が入ります。
すると、まず変更する際に影響範囲の調査が必要です。
複数の密結合のクラスがあるイメージですね。

 

テストに対するイメージとその誤解

(あとで)