はじめに
レガシーコード改善ガイドによると、レガシーコードとは(自動)テストのないコードです。本記事では、そんなレガシーコードの不具合を修正するときに必要な手法について説明します。
和田卓人さんによる下記のエッセイをベースに、レガシーコードの世界におけるアレンジを加えています。まずは下記のエッセイを読んでから、改めてこの記事を読んでみてください。
レガシーコードに対する不具合修正の手順
上記のエッセイにあった「不具合修正時のテストの手順」を、２点アレンジしています。
この流れに沿った修正が、レガシーコードの不具合に立ち向かうための道筋です。
- E2Eテスト(打鍵テスト)で不具合を再現させる
- 再現時と同じログ(スタックトレース)が出力されるテストコードを書く
- 2で書いたテストコードを実行し、落ちることを確認する(Red)
- 不具合を修正する
- 2で書いたテストコードが通ることを確認する(Green)
- テストコードが通っている状態を保ったまま、コードをリファクタリングする(Refactor)
- E2Eテストを再度実施し、不具合が修正されていることを確認する
以下、アレンジした箇所について説明します。
アレンジ1: テスト駆動開発のサイクルを追加
テスト駆動開発の基本的なサイクルは、Red→Green→Refactorです。
しかし、テストコードを書いていないときの習慣が残っていると、このRefactorを忘れがちです。
このため、手順に明記するようにしました。
テストコードを書いていないときは、修正の結果確認はE2Eテストに頼っていました。しかし、E2Eテストには手間や時間がかかるので、リファクタリングした後にそれを再実行するのは面倒です。このため、リファクタリングはおろそかになりがちでした。
しかし、上記の不具合修正の手順で書いたテストコードは、すぐに何度でも実行が可能です。このため、ストレスなく快適にリファクタリングができるはずです。
テストコードが通ったことを確認したら、そのコードをリファクタリングする必要性を思い出してください。
リファクタリング時の注意点
上記のリファクタリングですが、1つ注意点があります。
テストコードによるカバレッジが不十分な場合(100%ではない場合)は、今回修正したコードの範囲に留めてください。周辺のコードをリファクタリングしたくなった場合は、その部分のテストコードを書いてから実施するようにしましょう。
アレンジ2: E2Eテスト(打鍵テスト)を追加
「E2Eテスト」を手順に明記しました。
E2Eテストが必要な理由は「不具合の原因となるコードは、1箇所だけではないかもしれないから」です。仮に原因となるコードが2箇所以上だった場合は、ほかの箇所が修正されていないと、不具合は直りきっていないことになります。
しかし、そうなると、結局、E2Eテストが必要なことには変わりがないじゃないか。むしろテストコードを書く手間が増えている、という指摘があるかもしれません。
数日レベルの短期的なことを考えれば、その通りです。
それでもテストコードを書いたほうがいい理由
しかし、改めてテストコードを書かないケースと比較してみてください。不具合の修正を確認するために、アプリケーション全体の起動が必要な回数は減ったのではないでしょうか。
また、テストコードを書くコストを回収できるタイミングは、思ったより早くやってきます。下記の記事の「内部品質や保守性への投資はいつ実るのか？」を読んでみてください。
おわりに
上記の手順を踏むことで、テストのないレガシーコードに対して、テストを生み出すことができます。このやり方を繰り返せば、「レガシーコードをこれ以上増やさないようにする」力を身につけることができるでしょう。
しかし、実際にやってみると、思うようにはいかないケースがあるかもしれません。その一つは、テストコードを書くときに既存のコードの内容が理解できないというケースです。
そのようなときの助けとなる手法として、次回の記事では「仕様化テスト」について説明しようと思います。