読書会(JUnit実践入門)第1回議事録

=================================
「JUnit実践入門」を読む会第1回
=================================

.. csv-table:: 開催概要

  "日時", "2013年3月23日(土) 10:00-17:00"
  "場所", "川崎市教育文化会館第3会議室"
  "出席者(敬称略)", "高橋(智)、小棚木、岩室、遠藤、山中、門脇、吉本、村山、松永、中島、今井、高橋(徹)(書記)"

議事
====

表紙裏
------

* チートシートって訳すと何でしょう？
* もとの意味はカンニングペーパー

著者紹介
--------

* 著者紹介(巻末)を最初に朗読

目次より前の部分
----------------

* 扉裏の「本書は、小社刊『WEB+DB PRESS』Vol.69の…」を朗読
* 大幅に加筆って10倍以上だよねぇ
* 推薦のことば、はじめに、本書について、を朗読
* サンプルコードのライセンスが明言されているのはうれしい
* 謝辞
* 最近はTwitter IDを書籍に載せるようになったのですね

目次
----

* 目次をみて、ここまで書いている本はないのでいい本だと思った。

第1章
-----

* p.2下から3行目「良いプログラマのテストコードは、変更に強く、読みやすい」
の部分はテストコードのことを言っているのかな、ピンとこない
* テストコードの書き方が悪いと苦労する
* 自動テスト(JUnit)をやるならCI(継続的インテグレーション)をしないとテストコードが腐ってしまう
* SwingとかHTMLとか画面のテストは自動化できないよね？
* Web画面ならSeleniumを使って自動化できる
* SwingならFEST Swingを使って自動化できる
* 画面の自動テストは結果判定に必要な表示がDBまで必要なことも多く、モックと組み合わせる必要がある(さもないと全部結合しないと動かないテストになってしまう)
* 技術の世界は知らないことをできないことと言ってしまいがち
* この本で言うユニットテストは、開発者の作業領分のテストで、品質(QA)の領分のテストではないですよね
* 欠陥率(バグ密度)を事前に予想を立て、それに満たないと自らバグを埋めて修正するなんてことになりかねない
* (議論噴出し議事取りこぼし)
* p.4 ライセンス、CPLはEPLとほぼ同等と書かれている箇所について
* CPLにはEPLで削除された特許に厳しい条項がある
* OSI(Open Source Initiative)でCPLはdeprecated扱いとなっている
* NetBeansがJUnitをインストーラに同梱しなくなったのはCPLが原因
* JUnitがCPLをやめてEPLに移行する気配はなさそう
* 1刷の誤記が2刷でけっこう修正されている
* p.5上で環境セットアップに付録A、付録Bを参照しているので、いったん付録A、Bを読むことに

付録A 開発環境のセットアップ
----------------------------

* 誤記、正誤表ページにはまだ上がっていないようです
* p.412 A.1項の上2行目、(誤)Enviroment、(正)Environment
* p.413 注2 日本語サイトからダウンロードできないとは？
* Oracleの日本語ページは更新されてないものが多い
* どうしてEclipse 4.2ではだめなのだろう？
* 「私のプラグイン(more emacs)が動かないから(Eclipse側のバグ)」
* 4.2には少し動きがあやしいところがある
* p.418 注9 MacOS Xの場合、フォルダ自体を置き換えるとは？
* 前のフォルダが削除されてしまう、内容が統合されることはない
* Pleiadesの設定で-javaagentの記述について
* eclipse.exeのある場所にカレントディレクトリを移動しておかないと、この-javaagent記述では動かないのではないか？ eclipseには他にもカレントディレクトリが違うとだめな箇所がある
* Mac OS用の設定は、Pleiadesのドキュメントでは絶対パスで指定するようになっている
* MacOS Xの日本語ファイル名は、パ、ピ、などのUnicode正規化問題がある

付録B Eclipseの便利機能と設定
-----------------------------

* NetBeansなら設定不要で簡単なのに、と言ったら
* p.420「Eclipseは、Java開発におけるIDEとしてのデファクトスタンダードです」と強調されて朗読されてしまった
* p.421 「MS932(Shift_JIS)」について
* MS932とShift_JISは違う(IANA)。Windows_31J=MS932≠Shift_JIS
* プロジェクトのエンコーディングもUTF-8にすべき
* staticインポートのワイルドカード設定
* 重宝してます
* 知らなかった、これは便利
* p.424 [Ctrl]+[0]、ゼロとオーと区別がつきにくい
* p.425 コンテンツアシスト知らなかった、便利

第1章(復帰)
-----------

* p.9 テスト元クラスを指定しているのはなぜ？
* [次へ]を押すと、テスト元クラスのメソッド一覧を出すためでは
* p.13 注8 2バイト文字
* Unicodeは2バイトとは限らない
* p.13 assertThatと言い切っている
* assert構文
* Javaは配列境界を越えるアクセスにArrayIndexOutOfBoundsExceptionをスローするなど例外機構が充実しているからassertの必要性は少ないかも
* Javaプログラマーでassert構文知らない人が多いかも
* assertは実際のアプリケーションで使われているか？
  * (議事録作成事追記)openjdk8のソースコードを調査した結果2076箇所(grepツールで*.javaファイル内で"^[ ]*assert "にマッチする行)
* 日本語メソッド名に関して、テストツール(JUnit)への期待する機能で議論白熱
* メソッド名でテスト内容を表現するのは中途半端ではないか、テストケースの定義(テストの入力、期待値)とメソッド名を紐付けるような仕組みが必要では？
* それに対してメソッドレベルのテストでテストケースを文書化する意義はあるのか？
* ソースコード(テストコード)をきれいに書く方がよい
* クリティカルなソフトウェアではユニットテストレベルまで品質管理が要求される
* ユニットテストのテスト仕様を見て誰得なの？
* JUnitでは対応していない、それはスコープ外では
* …としばらくテストのあり方について議論が続きました
* テストメソッド名に入力値(3と4)とか書くのはどうなのか？
* テスト対象コードだけでは設計の意図が伝わらないことが多いが、テストコードがあることで意図が伝わるから、テストコードがあることが重要では？
* p.19 リスト1.8 浮動小数点の値同士の比較にis(==による完全一致)を使うのは正しく判定できないのでは？
* MatcherにはcloseToというのがあり範囲で判定できるので浮動小数点の比較に使うのでは？
* assertThatは書きにくいし読みにくいのでは？
* JUnitの実行順番は実行の都度変わるので、困ることもある
* 順番に依存して、順番により発生する不具合とかが再現できない
* ランダムな順で実行することで見つかるバグもある
* ランダムに実行し、その実行系列が保存/再現できるとよい
* p.25のコラムは、突っこみどころがあるが、本日は白熱議論が多いのでスルーしよう(コラムだし)
* p.30 「1つ目の引数」「2つめの引数」という表現は、乗数、被乗数という表現がある
* SIer的な開発で、ソフトウェアを別会社に開発委託をする場合、ユニットテストコードを納品対象にすると動作保証(瑕疵責任)が伴うので大抵は納品対象外にされるのでは？
* ユニットテストをテスト駆動開発で仕様と位置付けるなら、JUnitテストコードをテストとしてではなく仕様として納品してもらうこともあり得るか？
* 費用と期間を持つなら認められるだろうが、実際それは望めないことが多い
* SIer的な開発では「レガシーコード(テストコードのないプロジェクト)」になってしまう面もあるのか

次回は
------

p.31 下「ユニットテストの目的」からです。

[ 戻る ]