【失敗例2】単体テストを実施していたが、メンテナンスコストが増大し、やらなくなった
プロダクションコードの仕様変更や修正が発生した場合、テストケースもそれに合わせて修正していく必要があります。しかし、そのコストが大きくなり過ぎてメンテナンスできなくなり、テストケースが使われなくなっていった経験はないでしょうか? 長期にわたるプロジェクトや頻繁に開発者が変わるプロジェクトなどでよくみられます。
なぜメンテナンスコストがかかるのでしょうか?
【原因】1.テストコードが複雑過ぎて修正に時間がかかる
巨大なテストメソッドを作成したり、テストパターンを増やすためにコピペが多くなったりすると修正の影響範囲が大きくなるため、テストコードを理解することが困難になっていきます。
【原因】2.いつの間にか失敗するテストケースが増えて修正が大変
テストの実行に時間がかかるため、頻繁にテストを行わない、何かのイベントの区切りにしか行わない、軽微な修正なのでテストケースを実行しない、といったことが積み重なると、いつの間にかテストケースが失敗するようになります。そして、原因究明と修正に多くの時間がかかってしまいます。
対策としては、以下が挙げられます。
【対策】1.テストコードが複雑過ぎて修正に時間がかかる
一般的な対策
テストコードもプロダクションコードと同様に、保守の間は利用され続けるものです。メンテナンス性を考えて、複雑になり過ぎないように重複をまとめたり、分割したりするなど、しっかり設計をして実装するべきです。テストパターンを増やすにはテストコードのコピペではなく、JUnitのパラメータライズを使うことで、1つのテストケースで複数のパターンをテストできるようになります。
さらにJtestによる対策「シンプルなテストケース作成を標準化」
JUnitのパラメータライズは【失敗例1】でも紹介したテンプレート機能で簡単に作成することができます。また、さまざまなテンプレート作成機能を使うことで、テストケースの実装を標準化することができます。経験の少ない開発者でも一定のレベルで定型化されたテストケースを作成することができるため、複雑化を防ぎます。
【対策】2.いつの間にか失敗するテストケースが増えて修正が大変
一般的な対策
いつでもテストを自動で実行する仕組みを作ります。ビルドや単体テストを自動的に実行するCI環境を構築することで、コミットのタイミングでテストを実行するなど、開発者が意識せずに常にテストが実行される環境を作れるため、テストの失敗を早めに検知し、修正することができます。
さらにJtestによる対策「修正の手間を省き、いつでも実行可能な環境を構築」
アサートが失敗したテストケースにおいては、実行後期待通りの結果が得られていることが確認できれば、簡単に期待値を更新することができます。
テストの実行も、Jtestを使えば変更箇所だけテストを実行することができるため、テスト実行に時間がかかって待ちが発生することもなくなり、テンポ良くテストを行うことができます。
また、JtestはCIツールとの連携も可能です。特にJenkinsであれば、Parasoft社の提供しているプラグインを利用することもできます。また、テクマトリックスでは「Jenkins Package Platform for Java」という、静的解析や単体テストの実行環境を整備するためのソリューションを提供しています。
Jtestの無料体験版を入手!
Jtestの無料体験版を配布しております。以下のリンクからダウンロード可能です。