読書会(JUnit実践入門)第2回議事録
[ 戻る ]
=================================
「JUnit実践入門」を読む会 第2回
=================================
開催概要
=================================
"日時","2013年4月20日(土) 10:00-17:00"
"場所", "川崎市教育文化会館 第3会議室"
"出席者(敬称略)", 高橋(徹)、高橋(智)、町田、小棚木、岩室、
遠藤、山中、門脇、北郷、吉本、村山、松永、
中島、祝迫、山口(書記)"
議事
=================================
p31.ユニットテストの目的
---------------------------------
*リグレッションという単語について
->デグレーションは日本独自な言い回しの説もある
->デグレーションを直訳すると退行等の意味がある
->一般的にはリグレッションと呼んだ方がよいのでは
*ユニットテストという単語について
->デベロッパーテストとも呼ぶ
*ユニットテストをより強力に活用する開発手法について
->テスト駆動開発がある
p32.ユニットテストのフレームワーク
---------------------------------
*JUnit以外のフレームワークについて
->TestNG等がある
->NetBeans7以降からはデフォルトでTestNGが入っている
->JUnitが入っていないのはライセンスの都合なのか？
->NetBeansインストール時にネットワークに接続していれば、
JUnitのダウンロードを行うことができる
->ネットワークに接続されていない場合、
JUnitを使う設定に難がある
p33.ユニットテストのパターン
---------------------------------
*xUnit Test Patternsについて
->ほとんど記事をWEBサイトで参照可能
->kindle版がある
*誤植を発見
->p35. Column「テストケースとドキュメント」の注bにて、
訳者の児玉さんの名前が誤っている
*コメントの多いコードに不具合が多いについて
->必ずしもそうではない
->初心者にはコメントを極端に記述したり、全くしない傾向が強く、
中級者は少量の記述になり、上級者はほどほどのコメントを記述できる
->オープンソースにはコメントが少ないものが多い
->コメントアウトしているコードが含まれているコードは良くない
*Javaのコンパイラや実行環境が異なるときにテストの実行順序が変わる
ということはあるのか
->マルチスレッドを使用した処理のテストを行った場合におこりえるのでは
->シングルトンオブジェクトを使用したコードをテストする場合
結局どうするのが一番良いのかよく分からない
p40.テストメソッドのthrows句
---------------------------------
*Throws句にExceptionなどの基底となる例外クラスを指定することを禁止
している理由はなんなのか
->ExceptionをThrowsするとRuntimeExceptionもキャッチしてしまうから
->ThrowAbbleをThrowsするとErrorClassもキャッチしてしまうから
->単純に何でもExceptionにする人がいるから
p42.テストケース
---------------------------------
*ソフトウェアのテストでは許容差についての規定が存在しない
ハードウェアの場合と同じように許容差についての規定をJISなどで
行ってほしい
->バックグラウンドでウィルスソフトが実行中の場合、
テストを実施するとレスポンスが悪くなる等
p44.実測値と期待値
---------------------------------
*メソッド名に日本語使っているなら、変数名も日本語じゃだめなのか。
->メソッド名に比べて変数名を日本語で記述することは多いからではないか。
p47.テストフィクスチャ
---------------------------------
*コメント箇所も日本語が解りやすい。
->ここは自動生成されるスニペットで定期すると良い
p49.JUnitのアサーション
---------------------------------
*Object expected = ...; の「...」について
->javaの予約後なので、例として使用しないほうが良い
p51.@Test - テストメソッドを宣言する
---------------------------------
*単語としての「Argument」、「Parameter」の使いどころ
->厳密な定義はなく、どちらでもよいのでは。
p52.@Ignore - テストの実行から除外する
---------------------------------
*リスト3.11の下記のコードについて
->下記のコードはこのように記述したほうがよいのでは
assertThat('actual', is(100));
↓
assertThat('actual', is(100L));
*タイムアウトを使用したテストについて
->開発者個人で行うテストの場合は必要ないと思う
->CIでテストを行うさいにはタイムアウトは必要ではないか
環境でなんらかの問題が発生し、どこかでこけた場合にテストが終わらない
ことがあるから
->@Test外せばいいと思う。
->@Test 外すとどれがテストメソッドがわからない
->@IgnoreをつけるとJenkinsの場合、スキップしたテストとして報告される
p52.@Before - テストの実行前に処理を行う
---------------------------------
*リスト3.13のコード中 変数につけられたsutという単語について
->SystemUnderTest = sut という単語を皆使ってますか？
->つかってない。解りづらい
->xUnit Test Patterns の Testing Terminorogyに単語は掲載されている
->ここはcalcが解りやすい
->たくさんのテストコードを生成していると、
クラス名にあわせた変数名にするのが面倒なのかな
->面倒さより分かりやすさを重視すべきだからcalc
->テスト屋の立場からすると、そのテスト対象がなにのクラスなのかは関係なく、
どれがテスト対象なのかをすぐ分かるほうが良いから、sutなのかも
->テスト屋さんがテストコードの実行をするとは思えない。
->テストコードを記述し実行するのは開発者。開発者視点からsutは分かりづらい
p55.Column jUnit3スタイルのテスト
---------------------------------
*jUnit3でのsetup,tearDownメソッドについて
->protected でもpublicでも良いのか
->問題ない。
p56.@AfterClass - テストの実行後に一度だけ処理を行う
---------------------------------
*@AfterClassが実行されるタイミングについて良く分からない
->（宿題、課題）
*全テストの開始前、終了後に処理を行う機能がほしい
->Mavanでディレクトリ配下を調べて対象のクラスを読み込んだりしている
->JUnitで行いたい
->@Suiteを使用すればよい
->テスト対象のクラスを列挙しないといけないので面倒
--クラスローダーは自分でかけばネットワークからダウンロードしたりすることができる。
-->自分で実装する必要がある
p58.コンストラクタを検証するテスト
---------------------------------
*リスト3.19のコード中 instanceという変数について
->実測値でもあるのならactualでよいのでは
p67.CoreMatchersが提供するMatcher
---------------------------------
*isNullがあればいいのに
*isEmptyStringならemptyはisEmptyにすればいいのに
p73.カスタムMatcherの作成手順
--------------------------------
*リスト4.7のコード中 date型ではなくCalender型を使用しているのはなぜ
->Date型では現在のバージョンでは年月日を取得することができない
->デリゲードされているため
P76.テスト失敗メッセージの確認
--------------------------------
*誤植を発見
-->テストに失敗した期待値が違う
-->2012 1/12ではないか。
次回は
=================================
p.89 「Categories -特定カデコリのテストクラスをまとめて実行する」からです。
[ 戻る ]