回答編集履歴
2
コメントに対しての返答
answer
CHANGED
|
@@ -13,4 +13,22 @@
|
|
|
13
13
|
デグレのことを言っているのであれば、影響調査に時間を割く方が工数は掛からないと思います。
|
|
14
14
|
|
|
15
15
|
結構勘違いしている人がいるのですが、ユニットテストの導入時の初期工数はかなりでかいです。
|
|
16
|
-
※再テストの工数はかなり減りますが、仕様変更があった場合、対象のテストロジックも全て変更になることに注意して下さい。（ユニットテスト用のコードメンテナンスの工数が余計に掛かる）
|
|
16
|
+
※再テストの工数はかなり減りますが、仕様変更があった場合、対象のテストロジックも全て変更になることに注意して下さい。（ユニットテスト用のコードメンテナンスの工数が余計に掛かる）
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
少し長くなったので追記：
|
|
20
|
+
個人的な意見になってしまうのですが、
|
|
21
|
+
|
|
22
|
+
ユニットテストは仕様のテストではなく、プログラムが想定する結果を返却するかの観点で行います。
|
|
23
|
+
※同じように思えますが、全てのクラスが期待通りの結果を返却をしたら、仕様が満たされるって感じです。
|
|
24
|
+
|
|
25
|
+
なので、ユニットテストの単位はクラス単位に行います。（機能単位ではありません）
|
|
26
|
+
導入になれる為にも、軽い共通のクラスから行うのが良いと思います。（引数が少なくて、結果が分かりやすいもの）
|
|
27
|
+
次にその他のmodelクラスですね。（FuelPHPで自動生成されているものは除外）
|
|
28
|
+
次に拡張しているCore系をやって行く感じが良いかと。。（テスト観点とかが難しい）
|
|
29
|
+
|
|
30
|
+
自分の場合、controllerには導入しないですね、
|
|
31
|
+
結局画面からのリクエストが正しいかなどで、画面を動かすことになるので。。。（二度手間）
|
|
32
|
+
|
|
33
|
+
model内で直接リクエスト情報を取ってたりしたら、そのクラスについては導入はあきらめた方が良いと思います。
|
|
34
|
+
（modelが画面に依存している状態だから、controllerと同じ状態※FuelPHP本来の考え方ならありえないはずです、、、）
|
1
修正
answer
CHANGED
|
@@ -9,6 +9,7 @@
|
|
|
9
9
|
その辺は問題ないのでしょうか？
|
|
10
10
|
|
|
11
11
|
> 1つ修正すると、違うところでバグが発生するという状況です。
|
|
12
|
+
|
|
12
13
|
デグレのことを言っているのであれば、影響調査に時間を割く方が工数は掛からないと思います。
|
|
13
14
|
|
|
14
15
|
結構勘違いしている人がいるのですが、ユニットテストの導入時の初期工数はかなりでかいです。
|