回答編集履歴
2
ad
test
CHANGED
|
@@ -4,4 +4,4 @@
|
|
|
4
4
|
レイヤーが違う。並列にするのはおかしい。
|
|
5
5
|
|
|
6
6
|
|
|
7
|
-
※
|
|
7
|
+
※個人的な事情で申し訳ないですが回答大半削ってます。
|
1
残す意味が全くない 質問者の対応に気持ち悪さすら感じるので編集。運営に諸々問い合わせて削除依頼済み
test
CHANGED
|
@@ -1,45 +1,7 @@
|
|
|
1
|
-
# 前提
|
|
2
|
-
質問者は業務且つ指示者がある状態で本質問を投稿してきており、
|
|
3
|
-
質問者が所属するプロジェクトと定義や意味が違う可能性があります。
|
|
4
|
-
つまり、私の回答によってプロジェクトの方針と違ったとしても一切の責任は取りませんし、
|
|
5
|
-
|
|
1
|
+
デバッグ：問題解決の手段
|
|
6
|
-
|
|
2
|
+
単体テスト：工程の１つ
|
|
7
3
|
|
|
8
|
-
# 一般論（というか私の経験上）
|
|
9
|
-
|
|
10
|
-
デバッグ：手段
|
|
11
|
-
単体テスト：工程
|
|
12
|
-
|
|
13
|
-
なのでそもそものレイヤーが違います。
|
|
14
|
-
レイヤーが違う
|
|
4
|
+
レイヤーが違う。並列にするのはおかしい。
|
|
15
|
-
|
|
16
|
-
問題の調査から解決までの一連を広義で「デバッグ」と称し、
|
|
17
|
-
「調査」の過程自体を狭義で「デバッグ」と称すこともあると思います。
|
|
18
|
-
|
|
19
|
-
故に、
|
|
20
|
-
> デバッグしながら開発した場合は、単体テストは不要なのでしょうか？
|
|
21
|
-
|
|
22
|
-
上記は大きく「No」です。
|
|
23
|
-
|
|
24
|
-
「開発した」ということは、まだ製造工程にあるはずです。
|
|
25
|
-
開発段階で起きた不具合はあくまで点に過ぎず、単体テストによって「機能」を確認した時に
|
|
26
|
-
不具合が起きないことを担保するわけではないからです。
|
|
27
|
-
「要件通りできていること」を確認するのが「テスト工程」（単体テストに限らず）。
|
|
28
|
-
|
|
29
|
-
段階に限らず問題が起きたときに解決策として用いる手段が「デバッグ」
|
|
30
|
-
|
|
31
|
-
むしろデバッグせずに開発ってどんな天才？
|
|
32
|
-
プロジェクトの慣習かもしれないので、あくまで私個人としてその考え方には疑問しかないです。
|
|
33
|
-
|
|
34
|
-
ただ、「この工程が必要かどうか」を判断するのはプロジェクトのマネジメントを担当している人なので、
|
|
35
|
-
「こういうケースはテスト不要」というのがプロジェクト方針として定義されていれば、「不要」でしょうけどね。
|
|
36
|
-
|
|
37
|
-
一般的に「確認したよ」って言葉だけでエンドユーザに提供するアプリケーションやシステムをリリースする現場って、数人だけで回してる社内システムくらいしかないと思うので、大抵は「どういう確認をすればこの機能はリリースできるか」という観点で単体テスト仕様書を作って、１つ１つチェックして全てOKになるまでテスト工程は終わらないわけです。
|
|
38
|
-
不具合があれば修正し、再度テストを行う（どこまでテストを行うかは影響範囲次第ですし、仕様不良なども見つかれば設計書の修正からまた追加実装し、追加テストを行うこともあるでしょう）
|
|
39
|
-
|
|
40
|
-
------
|
|
41
|
-
|
|
42
|
-
若干殴り書きになってしまいましたが、全部理解するのは現段階では難しいと思うので、
|
|
43
|
-
「一般論」冒頭に書いた「手段と工程なのでレイヤーが全く違う」というところだけ念頭に置いて再度考えてみてください。
|
|
44
5
|
|
|
45
6
|
|
|
7
|
+
※ただし、運営に諸々問い合わせて削除依頼済み
|