xutp/chapter24_testcase_class_per_fixture.txt at master · yujiorama/xutp · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
{{toc}}

! Testcase Class per Fixture

!! がいよう
''How do we organize our Test Methods onto Testcase Classes?''

'''フィクスチャーの共通性を元にテストメソッドをまとめる'''

!! がいようのほそく
* ''Test Methods'' (pp.348) が増加するにつれて、どの ''Testcase Class'' (pp.373) に配置するかを決めなければいけなくなる
* ''Testcase Class per Fixture''
** 私達が「テストの全体像を容易に理解できるようになる」ことに作用するテスト組織化の戦略
** フィクスチャーセットアップの方法にも影響する
** ''Test Automation Framework'' (pp.298) が提供する ''Implicit Setup'' (pp.424) の仕組みが効果的に使えるようになります

!! How It Works

* 必要とするテストフィクスチャーを元にテストメソッドを集めます
* ''Implicit Setup'' のようなフィクスチャーを生成するロジックを setUp メソッドに移動することができます
* 4 フェーズテスト (pp.358) における exercise、および verify フェーズに集中することができます

!! When to Use It

* 同じフィクスチャーを使うテストメソッドのグループがあり、それらを単純にしたいときのためのパターンです
* 個々のフィクスチャーが必要な場合はあんまり意味がありません
** テストメソッドが 1 つだけの大量のテストクラスが作成されるからです
** ''Testcase Class per Feature (pp.624) か ''Testcase Class per Class'' (pp.617) を使うべきです

* テストの実行が始まる状態を容易に把握できるようになります
* テストケースクラスごとのテストメソッドが同じ並び方になります
** IDE の "メソッドブラウザ" や "アウトラインビュー" で一瞥できます
** だいぶ前に商用リリースしたコードの ''Missing Unit Tests'' (Production Bugs, pp.268) を見つけるのに便利です

* 振る舞い駆動開発におけるテスティング、仕様決定の重要なポイントです
* アサーションが 1 つだけのようなとても短いテストメソッドを書くようになります
* テストの期待結果の要約を含むような命名規約と組み合せることで、''Tests as Documentation'' (pp.23) を推進します

!! Implementation Notes

* フィクスチャの生成は ''Test Automation Framework'' が setUp メソッドで行う
* フィクスチャへの参照はインスタンス変数に持たなければなりません
* クラス変数を使わないように注意
** ''Shared Fixture'' (pp.317) になりやすい
** ひきずられて ''Erratic Test'' (pp.228) になりやすい

* コラム "There's Always an Exception" (pp.384)
** インスタンス変数を使っているからといって ''Independent Test'' (pp.42) にならない xUnit ファミリーを紹介
** NUnit2.0、TestNG
** NUnit の作者は「失敗だった」と言っている

* 各テストケースクラスには 1 つのテストフィクスチャ
* テストケースクラスの名前はそのフィクスチャを元にしたものになるのが当然

* 同様に、テストメソッドの名前は exercise する SUT を元にしたものになる
** SUT メソッドの引数の特徴やメソッド呼び出しの期待結果とか

* 副作用: 1 つの SUT クラスを検証するためにたくさんのテストケースクラスが作られてしまう
** ネストしたフォルダ/パッケージ/名前空間を使ってまとめる
** ''Test Enumeration'' (pp.399) を使っているなら、''AllTests Suite'' (Named Test Suite, pp.592) によって 1 つのテストスイートにまとめる

* 副作用: SUT の 1 つの機能に対するテストがたくさんのテストケースにちらばる
** 機能間の相互依存性を際立たせるのでよいことかもしれない

* 機能間の関連がほとんどなくては不安になったときの処置
** テストを ''Testcase Class per Feature'' にリファクタリングする
** SUT が責務を持ちすぎていることを意味するので SUT をリファクタリングする

!! Motivating Example

* ''Testcase Class per Class'' パターンで構成された Flight クラスのテスト
** 3 つの状態 (Unscheduled, Schedule, AwaitingApproval)
** 4 つのメソッド (schedule, requestApproval, deSchedule, approve)

!! Refactoring Notes

* フィクスチャーの生成における ''Test Code Duplication'' (pp.213) を取り除きます

* 元のテストクラスが使っているフィクスチャーが 1 つになるまで、これらのプロセスを繰り返します
## フィクスチャーとして生成するクラスの数と、どのテストメソッドを 1 つのテストクラスに入れるのかを決める
## ''クラスの抽出'' により、必要なフィクスチャーを説明した名前を付けたテストケースクラスを作成する
## ''メソッドの移動'' により、必要なインスタンス変数と一緒にテストメソッドを新しいクラスに移動する


* 全て完了するまでの間に、テストケースクラスがコンパイル・実行できるようにしましょう

* ''Testcase Class per Fixture'' パターンの利点を最大化するための残り 2 つの手順
## 各テストメソッドにあるフィクスチャーの生成ロジックを、setUp メソッドに移す (''Implicit Setup'' にする)
*** 同じフィクスチャーを使うテストメソッドを集めているからできるはず
## テストメソッドの名前を、それが検証する結果を表すように変更する
*** テストケースクラス名からテストの初期状態は分かるので、初期状態に関する表現はメソッド名から除去してもよい

* リファクタリングによって、テストメソッド名にテストすることと期待結果を含めるような世界から開放された

!!! Example: Testcase Class per Fixture