9日目：単体テスト自動化～JUnitの一歩進んだ使い方～

はじめに

このAdvent Calendarでは、過去に私が書いたテストや品質に関する記事の紹介をします。
本日紹介する記事はこちらです。

https://www.nttdata.com/jp/ja/trends/data-insight/2012/083001

掲載日：2012年8月30日
掲載メディア：DATA INSIGHT（NTT DATA）

生成AIによる要約

この記事では、Javaの単体テスト自動化の現状と課題、およびその改善へ向けた取り組みを紹介しています。調査では多くのプロジェクトで単体テストツールの利用率が約 27.7％にとどまっており、JUnitなどxUnit系フレームワークを使ったテスト自動化は十分に普及していないことを指摘しています。
JUnitのメリットとしては、テスト用コード（テストコード）を書いて単体テストを自動実行できる点や、統合開発環境（IDE）との親和性が高く、回帰テストやTDD（テスト駆動開発）で有効であることが挙げられています。一方で、テストコードの作成やメンテナンスのためのコスト増が大きな導入の障壁になっていると説明されています。
こうした課題を解決するため、ソースコードのロジック解析によるテストコード自動生成や、仕様に基づいた「ブラックボックステスト」をサポートするツール（例えばExcel／CSVで作成したテストケース表からテストコードを生成する手法）など、新しい単体テスト自動化支援技術の登場が期待されていると述べています。

記事に対する補足、訂正、最新情報など

• この記事は、当時非常に多くのアクセスがあり、長期間ランキング上位にありました。理由としては、今で言えば“バズった”、より正確に言えば“軽く炎上した”ためです。いわゆるエゴサをしていたので、寄せられたご意見は把握しており、若干心が痛んだのを覚えています。

• Excelでテスト項目表・テストケース表を作成し、そこからJUnitコードを生成するという手順は、軽量に単体テストを書けるJUnitの利点を潰してしまう、前時代的なやり方だという批判はもっともだと思います。

• とはいえ、この方法を選ばざるを得なかったのには、多くの大規模プロジェクトを抱えるSIerならではの背景がありました。記事中では触れていなかったため、共感されにくかったのだと思います。具体的には、仕様に基づく網羅的なテストが求められたこと、すべての開発者がJUnitを書けるわけではなかったこと、「確実にテストした」とお客様に説明する責任があったことなどの事情から、当時はこのようなプロセスになっていました。

• この記事を書いた後、品質と効率のバランスを考えて、テスト対象ソースコードを解析してテストコードを自動生成する機能を追加するなど、ツールの改良も行いました。ただし、「テスト対象を基にテストコードを作ることにどれだけ意味があるのか」というモヤモヤはずっと残っています。テストの基本はブラックボックスであるべき、という考えはいまも変わりません。

• 記事中に記載されているAgitarOneおよびCodePro Analytixへのリンクは、現在いずれも公開されていないようです。あらかじめご了承ください。

さいごに

この時期は、この記事のツール以外にも社内向けのテストツールをいくつも開発していました。ツール開発自体はとても楽しいのですが、その一方でツールそのものの品質保証やメンテナンスの負荷が大きいことも痛感しました。今では、可能な限り市販のテストツールやオープンソースツールに任せたい、というのが私のスタンスです。

ここまでお読みいただき、ありがとうございました。明日の投稿もどうぞお楽しみに。