バグの修正の前に再現テストを先に書く

2003年以降、私自身のソフトウェア開発は、テスト駆動開発が基本です。ただ、私自身が開発せずに、指導やレビューを行ったテスト駆動開発もあります。

経験した中で大規模で技術的に複雑だったテスト駆動開発は、以下の二つです。

• 2003年2月から2009年8月：Linux/C++によるデジタル複合機コントローラソフトウェア
• 2013年7月から20015年5月：Linux/Goによるデジタル複合機コントローラソフトウェア

残念ながらどちらのプロジェクトも最終的なデジタル複合機製品とはなりませんでした。

コピー/スキャン/プリントなどの複合機※をテスト駆動開発でスクラッチから開発した経験やノウハウは、部分的にJaSST'18 Tokyoの招待講演とJaSST'19 Tokaiの特別講演で話しました。
※ 今日のオフィスにある富士ゼロックスやリコーなどのデジタル複合機のソフトウェアは、ソースコードの量として1,000万行に達しているようです。残念ながら、ほとんどが自動テストがないレガシーコードです。

テスト駆動開発の経験がない人がテスト駆動開発のプロジェクトに従事したときに、テストコードを書くことに加えて難しいのは「テストファースト開発」と「バグの修正の前に再現テストを先に書く」ことです。

不具合への対処手順

何らかの不具合が発見、あるいは報告されたときの手順は次のようになります。

1. 不具合の原因の調査
2. 不具合の再現テストの作成
3. 不具合の修正

1.で原因の調査を行って、不具合の原因を調べます。原因は、条件判定の漏れや間違いだったり、想定外の事象が発生していたりとさまざまです。

2.では、原因が分かったので、「パスしない再現テストを作成する」ことが重要です。そのようなテストを作成した経験のないエンジニアの場合、作成せずにいきなり不具合修正を行ってしまいます。不具合を修正したと報告を受けたときに、「再現テストは書いた？」と聞くと「書いていません」という返事をもらったことが多々ありました。

最後に不具合を修正して、2.で作成したテストがパスすることを確認します。同時に、既存のすべてのテストがパスすることも確認します。

不具合の原因によっては、再現テストを書くのが非常に難しことがあります。特に不具合の発生がスレッドのスケジューリングに依存する場合です。その場合には、ロギングを工夫して、テストコードからスケジューリングを指定できる機構を入れたこともあります。

まとめ

パスしない再現テストを書く習慣を持つことは重要です。テスト駆動開発を行っているのであれば、テストファースト開発と共に意識して行ってみてください。