テストコードのリファクタリング #jjug_r33

とーます @grimrose

テストコードのリファクタリングはプロダクションとは違うアプローチが必要。 #jjug_r33

KUBOTA Yuji @sugarlife

テストコードの特徴。似たようなコードが増える。各テストケースで完結する。通常のコードではそうでもないのにコピペがやたら蔓延してるのは実感する #jjug_r33

Hideki Igarashi @ganta0087

デモ: ArrayListのテスト "状態を持っているのでテストが難しい" #jjug #jjug_r33

KUBOTA Yuji @sugarlife

とはいえ、リファクタリングを進めると一つのメソッドで完結しなくなる等でテストの見通しは悪くなる。 #jjug_r33

Hideki Igarashi @ganta0087

"@ RunWith(Enclosed.class)でテストメソッドを構造化。初期状態が共通なものをまとめる。" #jjug #jjug_r33

yemoto @kaakaa_hoe_prog

Enclosedアノテーション。テストの初期状態がきょうつうのものあをインナークラスにまとめることが出来る。 #jiug

ゆとり🇺🇦 @megascus

JUnitの何が問題かというと、色々機能はあるけれども覚えきれないということだなぁ。Theoryとかも覚えてらんない。 #jjug_r33

シモムラRι(｀ロ´)ノ @shimosuk

すげー興奮してきた。テストコードリファクタリングしたい！！#jjug_r33

Hideki Igarashi @ganta0087

社内のテスト研修にEnclosedについて入れたほうがいいなぁ…

とーます @grimrose

QuickJUnitだと、Enclosedと相性悪いんだよなぁ…

yemoto @kaakaa_hoe_prog

Enclosedでは各テストケースの記述が簡単になるが、setupが煩雑になる恐れがある #jiug

とーます @grimrose

Enclosedのいいところは、JUnitのレポートも見やすくなるんだよね。

神速 @sinsoku_listy

へぇー、JavaでもContextを分けてJUnitでテスト書けるのか

Suzuki Junya @suzukij

Enclosedテストランナーでテストをグルーピングでスッキリ。WebDBプレスでも紹介されてたけど使ってなかったなー。使わねば。

とーます @grimrose

個人的には[at]Theoriesのが好き。 #jjug_r33

eiryu @eiryu

parameterizedよりtheoriesがおすすめ #jjug_r33

Hideki Igarashi @ganta0087

"JUnitではパラメタライズテストに2つ方法があるが、Theoriesランナーを使うのがオススメ。" #jjug #jjug_r33

jaianne @jaianne

いいわー、テストコードリファクタリング。 本買ってしまいそう、というか買うわｗ http://t.co/A32adDJs #jjug_r33

とーます @grimrose

テストにもパラメータオブジェクトパターンを利用する。 #jjug_r33

yemoto @kaakaa_hoe_prog

Theoriesによるパラメーター化テスト。テストケースへの引数が多くなる事を防ぐために、引数はネストクラスにまとめる #jiug

ゆとり🇺🇦 @megascus

@null TheoryはSpockの下位互換でしか無いイメージ。 #jjug_r33

Hideki Igarashi @ganta0087

"パラメーターを格納するFixtureクラスを用意して、@ Theoryアノテーションを付けたテストメソッドに渡す。@ DataPointsアノテーション付きメソッドでパラメーターを用意する。" #jjug #jjug_r33

tt4cs @tt4cs

JUnitの講演は聴きたかったな. 刻一刻と画面のキャプチャを撮ってExcelシートに貼り付けるのがテストだ！って複数の販社さんから言われる現状では, テストの自動化自体が禁句なんだけども.

Hideki Igarashi @ganta0087

"テストデータをYamlとかで外出しして読み込むこともできる" #jjug #jjug_r33

yemoto @kaakaa_hoe_prog

テストケースとテストデータを分離する。Theoriesではテストケースが増加しても可読性を損なわない #jiug