ある日のランチタイムのこと。
そのテストコード消したよ
私が携わっている開発は、現在3つのバージョンで開発が進んでいる。
私と同期は、別々のバージョンの開発をやっていて、お昼を食べながら、テストコードの話になった。
すると、同期が突然、
「いらないテストコード消したよ」
えっ？本当に？
開発開始時にテストフレームワークをいくつか調査し、導入手順を一人で作ったのに、なんとも言えない気持ちなった。
さらに、今回はテストコードを作ってないとか。
ただ、テストコードを消したり、作らなかったりしなければならない理由が何かしらあったに違いないので、同期に話を聞くと次の2つが話に挙がった。
- テストコードを修正しても成功しない。
- テストコードの作成に時間がかかる。
テストコードを修正しても成功しない
「テストコードがあったから実行したら、テストが失敗して、修正したけど全然成功しないんだよね」
これは、テストコードを作成した前任者が、バグを改修した後にテストコードをバージョン管理に登録してないことで、テストコードが最新の状態でなくなっている。
後任者がテストを通るように修正しても時すでに遅し。実際の作業でいっぱいいっぱいになり、結局不要なテストは削除することになったという。
テストコードの作成に時間がかかる。
「テストコード書こうとしたんだけど、難しくてよくわからなかった。テストコード書くより動かした方がテストの消化も早かったし・・・」
初めてのテストフレームワークを使うとなると、使用者はテストフレームワークを学習するコストが必要になる。
同期が担当しているバージョンのスケジュールは、タイトなスケジュールだったこともあり、テストフレームワークを理解するための作業工数を確保できなかった。
何が問題だったのか
先ほどの２つの理由について、「問題はなんだったのか？」を自分なりに考えてみた。
「テストコードの重要性の理解の欠如」
「テストコードを修正しても成功しない」ことに対する問題は、「テストコードの重要性の理解の欠如」だと思う。
チーム内でも、テストコードをきちんと成功する状態でバージョン管理にコミットしていた人は、ほぼいない。
テストコードを成功する状態で管理しておけば、デグレ発生を早期に確認できるだけでなく、リグレッションも容易である。
このテストコードがあるメリットをプロジェクトリーダーをはじめ、担当者の理解が不足していたことで、テストコードを最新の状態に保てなかった。
初めて使うテストフレームワークを理解するためには、学習するためのコストが必要である。
テストしながら学ぶことも可能だが、それは開発スケジュールに余裕がある場合のみ可能なことだ。
今回の同期のように、タイトなスケジュールを計画された場合は、テストフレームワークを学習するための工数が確保されていないため、テストフレームワークの導入に失敗したと考える。
問題から学ぶこと
問題点から次の対策が重要だと思う。
- テストフレームワークの学習工数を盛り込んだ開発計画を立てる
- テストコードを最新状態に保つ重要性をテスト開始前に全員で共有する。
結局、計画とプロセスが重要なんだろうな。
おしまい。
