単体テストフレームワークはかなり古い時代からあります。
数十年前から存在しており、私が働いてきた数々のプロジェクトで何度も単体テストフレームワークを根付かせようという試みがありました。
私の周りだけかもしれませんが、単体テストフレームワークが根付いたプロジェクトはありません。
なぜ単体テストフレームワークが根付かないかを考えてみました。
テスト自動化
テスト自動化というと大まかに3通りくらいあるみたいです。
- 単体テストフレームワーク
- GUI自動化
- システムテスト自動化
「単体テストフレームワーク」は後ほど述べます。
GUI自動化は単体テストフレームワークと同じような視点から導入されたと思われますが、使用するツールが異なります。
GUIの自動化は「 Selenium」や「Ranorex」などを使います。こちらはかなり浸透しているようです。
「システムテスト自動化」は今のところできているところは稀だと思います。ツールを大掛かりに自作する必要があり、全自動化は工数に見合わないプロジェクトが多数ですので、現実的には、正常系の一部分だけの自動化というところです。
単体テストフレームワーク
単体テストフレームワークは、単体テストを自動化するツールです。
ドライバ、スタブを作って同時にコンパイルして実行するというのが単体テストフレームワークです。
一回作っておくと単体テストの再実行を行うことができます。改修するときに単体テストを全やりなおし、と平気で言えるのが気持ちいいです。
各プログラミング言語ごとに、無料、有料のフレームワークが多数あります。
例えば、C++ではGoogleTest, JavaではJUnit, PythonではPyUnitが有名です。
単体テストの時間はほぼコーディングの時間
ドライバとスタブを作るのが単体テストの時間になります。
主にはドライバを沢山つくります。ということは、単体テストをやる時間が2回目のコーディングの時間になります。
一般的に、ステップ実行のデバグよりも時間がかかりますし、使いこなすのも技術力が必要です。
アジャイルでは必須
アジャイルでは単体テストフレームワークは必須とされます。
ウォーターフォールより短いサイクルで機能追加、改修を行うので、自動化しているのを前提にしているところがあります。
ウォーターフォールであっても有効です。
改修時にステップ実行で全単体テストをやり直すことは不可能です。思いつかないところにバグが発生する可能性はどうしても払拭できないので、自動化をするのは正義でありとても重要と思います。
単体テストフレームワークが根付かない理由
私の周りではなぜか単体テストフレームワークが根付きません。ガチガチのウォーターフォールだからかもしれません。
何故か？を考えてみました。
以下のような理由かと思います。
- ステップ実行より工数がかかる
- ステップ実行と自動テストを両方覚える必要がある
- 改修で影響範囲を考える賢い人が多い ～何も考えずに自動テストという考えがなじまない
- 不良が出たらステップ実行しないと分からない
- C0カバレッジ100%とか言われるとつらい ステップ実行してしまう
ステップ実行より時間がかかる
上の方でも書きましたが、デバガのステップ実行よりも単体テストフレームワークの方が時間がかかります。
予算に余裕がないから、という理由で単体テストフレームワークの使用が避けられることがあります。
ほんの少しテスト予算を増やすだけなんですけど。。。それで手に入るものは大きいと思うのですが。
ステップ実行と自動テストを両方覚える必要がある
単体テストをやる人でデバガのステップ実行をできない人はいません。
ということは、単体テストフレームワークを導入する場合、新たに単体テストフレームワークの使い方を覚える必要があります。
この手間が作業者をやる気にさせないことかもしれません。ステップ実行で全部できることを何のためにやるんだと思います。
ステップ実行しかやったことがない人がプロジェクトマネージャになったりすると余計に、無駄な作業に思えるのかもしれません。
改修で影響範囲を考える賢い人が多い ～何も考えずに自動テストという考えがなじまない
日本のエンジニアは優秀すぎるのか、改修するとき影響範囲を考え再テストする範囲をしっかり決めることができます。
影響範囲なんか考えずに自動で全部できるよ、という考えがピンとこない人が多いのかもしれません。
不良が出たらステップ実行しないと分からない
単体テスト中でもシステムテストになっても不良が出たとき、単体テストフレームワークだけで不良の原因を特定するのは困難です。
ステップ実行してみていろいろ値を見て、実行してみて、やっと不良の原因が分かります。
単体テストフレームワークが無力だなと思うと、役に立たないという印象があるのかもしれません。
C0カバレッジ100%とか言われるとつらい ステップ実行してしまう
カバレッジを考えてC0, C1などと言われた場合、
ライブラリ関数やシステムコールは、そのまま通したいときと、エラーを返させたいことが交互に出てきます。
この切り替えができないフレームワークが多いです。できても面倒な手順が必要です。
ということで、C0カバレッジ100%のテストをやれと言われたら、単体テストフレームワークとステップ実行の併用をすることになります。
じゃぁ、全部、ステップ実行でよくない？という空気になりますね。
どうやったら根付く？
単体テストフレームワークがどうやったら根付くか？
偉い人が「やれ！」と言えばそれでやると思います。
問題は偉い人がその重要性を理解していないことにあります。現場のエンジニアも重要性をいまいち理解できていません。
細々と考え方を広めていくくらいしか思いつきません。
まとめ
単体テストフレームワークが根付かない理由を考えてみました。
根付かせるための策までは到達できていません。どうやったらみんなやってくれるのか、悩みは尽きません。
コメント