単体テストの考え方・使い方 #1 なぜ単体テストをするのか?

 最近テストについて勉強したいなと思い買った1冊。

単体テストの考え方/使い方


どっかの記事で紹介されててかってみました。

この内容から僕が勉強になった点をまとめていきます。


単体テストとは何か

まず単体テストとは何でしょう。
見るからに定義するのが難しそうですねー。(システムは多様ですし)

この本では以下の4つの性質を持つと言っています。
  • 実行が早い
  • 隔離されている
  • 小さい単位が対象となる
  • 自動で行える
なるほど。(わからん)
これは学派によって少しづつ定義が変わってくるようです。
後でこれも解説していきます。

なぜ単体テストを行うのか

なぜこんな面倒なテストなんかをしなければいけないのか?(やったことある人ならテストなんか二度としたくないはず)
結論から言うと、持続的にスピード感をもって開発を進めるためにはテストが必要だからです。

当たり前ですがシステムは成長するほどできること(機能)が増えていきます。
機能が増えるほどコードの量は多くなり、一つの変更の影響が大きくなっていきます。(ソフトウェアエントロピーの増大)
小規模の場合は影響範囲の調査は比較的簡単ですが、規模が大きくなるにつれ調査は実質不可能になっていきます。(いろんなところが複雑に影響しあっている)

修正の影響を自動で見つけ出す方法はないか?
これが単体テストの役割になるわけですね。

何かを開発するたびにテストを行うことで、元からある機能が問題なく動くことを確認できて、ちゃんと動くシステムをある程度のスピードで開発を進められるようになると。

良い単体テスト

まだまだ概念的な話が続きますが、良い単体テストを作るために気を付けるべきことがあります。
それは以下の4つです。
  • 保守が簡単
  • 人が考えて作る
  • 全てではなく重要な部分をテストしている
  • 開発サイクルにテストを含める

特に人が考える必要があるという点についてですが、これは機械的に単体テストを作ることを良しとしていません。なぜなら機械的に単体テストが良いのか悪いのかは判断できないからです。
機械でできるのは単体テストの結果、おかしいところがないかという実行の部分です。

システムがどういう振る舞いをするのか、何が正しいのかは結局人が判断するしかありません。


今回はここまで。



コメント