本日は、Java読書会BOF「JUnit実践入門」を読む会 第1回を開催しました。出席人数は12人、予想以上に議論が活発に行われた会となりました。
本日は、書記担当を引き受けましたのでこれから議事録を作成するのですが、議論がかなり活発にあったので、起こすのが大変です。議事録は数日内にJava読書会BOFのWebサイトにアップする予定です。
http://www.javareading.com/bof/
ですので、本ブログでは感想めいたものを書きます。
「JUnit実践入門」を読む会（第1回）を終えての感想
テストは、開発者(プログラマー）、開発リーダー、マネージャ、品質担当、などなどそれぞれ役割・立場によって認識が異なるので、今日は議論が沸騰しました。
ユニットテストを開発者の個人裁量の作業と捉えるか、品質保証活動の一環と捉えるかで、作業のアウトプットが変わってきます。テストファーストやJUnitの使われ方からすると、前者なんだろうと思います。
しかし、「ユニットテスト」をテスト計画の一部として位置付けると、現在のJUnitのツールとしての機能やアウトプットでは不十分で、テスト仕様／テスト結果のアウトプットを求められます。
議論が沸騰したことの一因は、人によってこの立場が違う、あるいは同じ人でも議論中に立場が行き来していたからかなと思いました。
日本のソフトウェア産業（SIerと呼ばれるソフトウェアの受注開発に限定かも）では、開発担当者に比べて品質担当者が少なく、品質保証活動としてのテストをテスト担当者ではなく開発担当者が継続して担うので、ユニットテストの位置づけが開発の領分か品質の領分か曖昧になっていることが一因ではと思いました。
次に、品質保証活動でのテストであれば、設計項目に対応した試験をすることになりますが、メソッド単位のテストはメソッドの設計は通常ソースコード（＋ドキュメントコメント）になり、それに基づきテストコードを作成してテストを実施することになります。ここで作成するテストコードをJUnitで作成することもできますが、JUnitには品質テスト機能（テストケースの定義、テスト実施状況の管理、成果物の生成などの支援）は備わってないので、必要であればテスト実施者が作業で補う必要があります。
話は変わって、テストコードのないプログラムを「レガシーコード」と呼びますが*1、SIerにおいてソフトウェア（全部あるいは一部）を外注化した場合、納品においてテストコードを含めてもらえるかどうか話題になりました。大方、難しい、あるいは費用による、ということです。ということで、内作でない場合、レガシーコードになるのは宿命なのかもしれません・・・。
Sphinx（ドキュメントツール）
Java読書会BOFの議事録は、Sphinxで文書化できるようReST形式で作成することになっています。
で、議事録を書き始めようとして、先月Windows 8に移行したあとにまだSphinxをインストールしていなかったことに気付き、Sphinxを入れるところから始めました。オールインワンのインストーラも用意されているのですが（Windows版）、ここはPythonからインストールすることに、そしたら、UnicodeDecodeErrorが起きてしまい、うむむーと。
どうやらSphinxの作業ディレクトリのフルパス中に日本語があると生じるようです。本日読書会後の懇親会で、Pythonは日本語環境が辛いねと話した直後だったので、ああぁ、という感じです。ReST形式ファイル自体が日本語ファイル名だとダメだよという指摘は見つかりましたが、作業ディレクトリの途中にあるのもダメというのは見つからなかったので原因がわかるのに苦労しました。
一応、次のURLにパッチが書かれていたのでそれを適用して対処しました。
http://sicafe.net/sphinx_memo/installAtWinNoAdmin.html#id6
さあ、やっと議事録が書き始められます。
*1:「レガシーコード改善ガイド」より
