回答編集履歴
2
コメントに対しての返答
test
CHANGED
|
@@ -29,3 +29,41 @@
|
|
|
29
29
|
結構勘違いしている人がいるのですが、ユニットテストの導入時の初期工数はかなりでかいです。
|
|
30
30
|
|
|
31
31
|
※再テストの工数はかなり減りますが、仕様変更があった場合、対象のテストロジックも全て変更になることに注意して下さい。（ユニットテスト用のコードメンテナンスの工数が余計に掛かる）
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
少し長くなったので追記：
|
|
38
|
+
|
|
39
|
+
個人的な意見になってしまうのですが、
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
|
|
43
|
+
ユニットテストは仕様のテストではなく、プログラムが想定する結果を返却するかの観点で行います。
|
|
44
|
+
|
|
45
|
+
※同じように思えますが、全てのクラスが期待通りの結果を返却をしたら、仕様が満たされるって感じです。
|
|
46
|
+
|
|
47
|
+
|
|
48
|
+
|
|
49
|
+
なので、ユニットテストの単位はクラス単位に行います。（機能単位ではありません）
|
|
50
|
+
|
|
51
|
+
導入になれる為にも、軽い共通のクラスから行うのが良いと思います。（引数が少なくて、結果が分かりやすいもの）
|
|
52
|
+
|
|
53
|
+
次にその他のmodelクラスですね。（FuelPHPで自動生成されているものは除外）
|
|
54
|
+
|
|
55
|
+
次に拡張しているCore系をやって行く感じが良いかと。。（テスト観点とかが難しい）
|
|
56
|
+
|
|
57
|
+
|
|
58
|
+
|
|
59
|
+
自分の場合、controllerには導入しないですね、
|
|
60
|
+
|
|
61
|
+
結局画面からのリクエストが正しいかなどで、画面を動かすことになるので。。。（二度手間）
|
|
62
|
+
|
|
63
|
+
|
|
64
|
+
|
|
65
|
+
model内で直接リクエスト情報を取ってたりしたら、そのクラスについては導入はあきらめた方が良いと思います。
|
|
66
|
+
|
|
67
|
+
（modelが画面に依存している状態だから、controllerと同じ状態※FuelPHP本来の考え方ならありえないはずです、、、）
|
|
68
|
+
|
|
69
|
+
|
1
修正
test
CHANGED
|
@@ -20,6 +20,8 @@
|
|
|
20
20
|
|
|
21
21
|
> 1つ修正すると、違うところでバグが発生するという状況です。
|
|
22
22
|
|
|
23
|
+
|
|
24
|
+
|
|
23
25
|
デグレのことを言っているのであれば、影響調査に時間を割く方が工数は掛からないと思います。
|
|
24
26
|
|
|
25
27
|
|