システム開発をやる上で、避けては通れないフェーズが「テスト」。
おそらく「テスト」と聞くだけでげんなりする人も多いかと思います。
今回は、最も初期に行なうテストである「単体テスト(UT)」について、
実施する目的や方法、品質面で考慮することなどを書いてみます。
まず、テストの目的について。
実装フェーズではプログラマがせっせとプログラム作成を進めるわけですが、
人間のやることなので、当然ながらバグが発生します。
もちろんバグは修正するのですが、パッと見では分からないような細かいバグの場合、
リリースまで誰も気づかず…なんてことも起こりかねません。
そういう事態を防ぐためにテストを行ない、バグを洗い出して端から修正して行くわけです。
さて、今回のテーマである単体テストですが、
これは実装を行なったプログラマ自身が、
自分の作成したプログラムをテストする工程を指すことが多いようです。
ほとんどの場合、プログラマは自分の担当する機能を一つずつ実装するので、
テストも一機能（＝単体:Unit）ずつ行うことになります。
その辺を踏まえて、今回の主題である「単体テストを信用するな」という話を。
前述の通り、単体テストは「自分が作ったものを自分でテスト」するのが基本です。
自分が作ったプログラムですから、その挙動は十分すぎるほど把握しているはずなので、
想定外の動きをすればすぐに「バグだ！」と気づくことでしょう。
しかし、ここには大きな落とし穴があります。
それは、プログラマ自身が「これが正しい」と考えている動きが、
必ずしも設計者の意図と一致していない可能性があるからです。
--- [単体テストを信用するな(2)]に続く ---
おそらく「テスト」と聞くだけでげんなりする人も多いかと思います。
今回は、最も初期に行なうテストである「単体テスト(UT)」について、
実施する目的や方法、品質面で考慮することなどを書いてみます。
まず、テストの目的について。
実装フェーズではプログラマがせっせとプログラム作成を進めるわけですが、
人間のやることなので、当然ながらバグが発生します。
もちろんバグは修正するのですが、パッと見では分からないような細かいバグの場合、
リリースまで誰も気づかず…なんてことも起こりかねません。
そういう事態を防ぐためにテストを行ない、バグを洗い出して端から修正して行くわけです。
さて、今回のテーマである単体テストですが、
これは実装を行なったプログラマ自身が、
自分の作成したプログラムをテストする工程を指すことが多いようです。
ほとんどの場合、プログラマは自分の担当する機能を一つずつ実装するので、
テストも一機能（＝単体:Unit）ずつ行うことになります。
その辺を踏まえて、今回の主題である「単体テストを信用するな」という話を。
前述の通り、単体テストは「自分が作ったものを自分でテスト」するのが基本です。
自分が作ったプログラムですから、その挙動は十分すぎるほど把握しているはずなので、
想定外の動きをすればすぐに「バグだ！」と気づくことでしょう。
しかし、ここには大きな落とし穴があります。
それは、プログラマ自身が「これが正しい」と考えている動きが、
必ずしも設計者の意図と一致していない可能性があるからです。
--- [単体テストを信用するな(2)]に続く ---
