テストコードは未来の自分への贈り物

今、4年ほど前に作ったシステムの改修・機能追加を手がけている。

その中に、Excelでレポートを出力する機能があって、当然4年も経てばMS-Officeのバージョンも変わるから今のバージョンでの動作試験をしないといけない。

Excelの出力処理はクラスを分割して切り分けているとはいえ、そのクラスのすべてのメソッドを網羅テストするのは骨の折れる作業である。

そんな中で、コードをリポジトリからチェックアウトする際に、ふと思い出した。

4年前、このコードは将来的にOfficeのバージョンが上がった場合に再テストする必要があるはずだから、ユニットテストのテストコードを書け、と指示していたのではなかったか？

納期が逼迫し、かなりつらい開発だった記憶がある。
TDDなど導入しておらず、テストコードは後付けだ。すべてのメソッドのテストケースを書くのは、大変な作業だ。ただでさえ、納期も迫っている中で、逆に生産性を下げかねないテストの実装をすべきかどうか、かなり悩んだ。

しかし、僕らは決断した。フレームワークと、共通部品だけはテストコードを書こうと。

当時からそのシステムは継続的な開発が見込まれていたし、将来的にWindowsやOfficeなど、システムが依存している環境のバージョンアップに伴う網羅テストは、必ず必要となるはずだった。

そして僕らは必死の力を振り絞ってテストを書いた。

あれから4年。網羅テストの機会は訪れた。
今回も工数に余裕はない。可能なかぎり、生産性を上げ、効率よく開発を進めねばならない。

しかし、今回の僕らには強い味方がいる。新規開発のときに書いた、テストコードだ。


今日ほど過去の自分や、当時のメンバーに感謝したことはない。

素晴らしい贈り物をもらった。

そう、テストコードは、未来の自分への贈り物なのだ。