何時使用調試與單元測試？

Question

我有點困惑有什麼更好的使用調試或寫單元測試？這是一般還是有些情況下調試比單元測試更好？還是應該使用它們？

感謝

Answer 1

調試將幫助您診斷非工作代碼。

單元測試提供以下信息：

1. 確定你的代碼的工作，無論是常見的場景和邊緣情況的重複的手段。他們可以讓你自信地重構你的代碼，它仍然有效。
2. 該代碼的可證明的規範。在沒有書面規範的情況下，您的單元測試是您的代碼規範。敏捷世界尤其如此。
3. 有助於構建結構良好的代碼。因爲你想單獨運行單元測試，所以你必須編寫你的測試類來接受不同的（有時是模擬的）數據源，匯等。通過鼓勵這些抽象和關注的分離，你的代碼將變得結構良好（你可以當然，在沒有單元測試的情況下編寫結構良好的代碼）

您的單元測試應該反覆運行（通常作爲構建過程的一部分）。如果你確實破壞了它們（通常是由於編程錯誤），然後是時候打開調試器來確定問題並相應地修正代碼（或者修改測試）。

Answer 2

如果你能重現bug的單元測試，使用單元測試。它會在錯誤得到解決後繼續使用，並在未來「保護」代碼。

如果您很難找到有問題的代碼，那麼調試可能是更好的解決方案。但是，當你知道問題出在哪裏時 - 寫一個測試，確保它失敗並修復錯誤。

調試需要更多時間，這是「一次性」解決方案。當你有選擇單元測試時，更喜歡單元測試。

Answer 3

單元測試用於確保代碼按預期工作。當您需要查找代碼無法按預期工作時，會使用調試。

Answer 4

調試和寫入單元測試是兩回事。理論上講，你的開發應該由覆蓋不同場景的單元測試來驅動。當你意識到代碼有問題並嘗試在運行時看到不同變量的值時，你可以調試，因此基本上只有在出現問題時才能進行調試。

Answer 5

另一種觀點：

總是千方百計，你可以做的單元測試。理想的做法是單獨測試每個組件，然後進行組件協作的集成測試。

然而，你在談論的是一個不同的問題：如果有什麼事情發生，你應該怎麼做，去嘗試編寫一個單元測試或運行調試器。這些並不是真正的選擇。如果出現問題並且您可以在單元測試中看到該行爲，那就很理想。但是你仍然需要找到行爲的原因。現在你的選擇是在添加日誌記錄和運行調試器之間進行的，並且我跟那些說使用日誌記錄的人投票，直到你不能。調試器時間不會爲代碼添加長期價值。日誌記錄會。

Answer 6

我認爲這個問題可以用比某些答案暗示的更深的方式來看待...雖然可能更適合編程堆棧交換。

一是如何調試和單元測試互動

• 單元測試第一可以防止調試

• 當事情是足夠硬的調試方法之一是停止調試您的問題，並開始單元的一些意見使用相似類型的有問題的輸入來測試相關的事物。您可能想嘗試簡化首先導致問題的輸入（假設您的系統是確定性的！）

• 與上述類似，您可以通過系統跟蹤有問題的代碼，並開始單元測試，用相同的輸入

單元測試可以被認爲是「提前調試」或「悲觀調試」，假設你將會有個bug，因此試着調試它立竿見影。如果您在考慮實際問題時這樣做，那更像是猜測代碼的特定部分中存在錯誤，並且您可以通過猜測輸入中斷來引發錯誤。