こちらの回答が複数のユーザーから「質問に対する回答となっていない投稿」という指摘を受けました。
とのご指摘が多数あったため、ベストアンサーを修正いたします。
尚、こちらは参考になった回答を引用しております。
前提
質問者は業務且つ指示者がある状態で本質問を投稿してきており、
質問者が所属するプロジェクトと定義や意味が違う可能性があります。
つまり、私の回答によってプロジェクトの方針と違ったとしても一切の責任は取りませんし、
赤の他人なので責任を問えないということは了承ください。
デバッグ:問題解決の手段
※様々な意見を聞くのはもちろん良いことだが、様々な方向性の意見を取り入れて適切に使い分けできるなら今回のような質問はしないはずなので
単体テスト:工程の1つ
一般論(というか私の経験上)
デバッグ:手段
単体テスト:工程
なのでそもそものレイヤーが違います。
レイヤーが違うので、並列にするのはおかしい話です。
レイヤーが違う。並列にするのはおかしい。
問題の調査から解決までの一連を広義で「デバッグ」と称し、
「調査」の過程自体を狭義で「デバッグ」と称すこともあると思います。
故に、
デバッグしながら開発した場合は、単体テストは不要なのでしょうか?
上記は大きく「No」です。
「開発した」ということは、まだ製造工程にあるはずです。
開発段階で起きた不具合はあくまで点に過ぎず、単体テストによって「機能」を確認した時に
不具合が起きないことを担保するわけではないからです。
「要件通りできていること」を確認するのが「テスト工程」(単体テストに限らず)。
段階に限らず問題が起きたときに解決策として用いる手段が「デバッグ」
むしろデバッグせずに開発ってどんな天才?
プロジェクトの慣習かもしれないので、あくまで私個人としてその考え方には疑問しかないです。
ただ、「この工程が必要かどうか」を判断するのはプロジェクトのマネジメントを担当している人なので、
「こういうケースはテスト不要」というのがプロジェクト方針として定義されていれば、「不要」でしょうけどね。
一般的に「確認したよ」って言葉だけでエンドユーザに提供するアプリケーションやシステムをリリースする現場って、数人だけで回してる社内システムくらいしかないと思うので、大抵は「どういう確認をすればこの機能はリリースできるか」という観点で単体テスト仕様書を作って、1つ1つチェックして全てOKになるまでテスト工程は終わらないわけです。
不具合があれば修正し、再度テストを行う(どこまでテストを行うかは影響範囲次第ですし、仕様不良なども見つかれば設計書の修正からまた追加実装し、追加テストを行うこともあるでしょう)
若干殴り書きになってしまいましたが、全部理解するのは現段階では難しいと思うので、
「一般論」冒頭に書いた「手段と工程なのでレイヤーが全く違う」というところだけ念頭に置いて再度考えてみてください。