我對撰寫測驗并受益于在 TDD 環境中編碼的優勢和/或只是提高我的應用程式的可靠性非常感興趣。
但是在閱讀更多內容并在我的一個專案中實作一些單元測驗后，我想知道為什么我要花額外的時間來撰寫測驗，而在之前，我使用 Postman 和編譯器的除錯器來檢查我的邏輯并且它運行良好。
我知道通過撰寫測驗，我們可以更好地理解流程的流程或捕獲否則很難找到的錯誤等；但我想知道是否值得花費更多時間和撰寫額外代碼的麻煩。
uj5u.com熱心網友回復：
您不會運行單元測驗來檢查您添加的代碼是否有效。您運行單元測驗以檢查您添加的代碼是否不會破壞現有代碼。
當您撰寫新的單元測驗時，它不會立即提供任何值，因為它只是測驗您的新組件/類/函式是否按預期作業，就像您提到的那樣，您可以使用其他工具輕松檢查自己，而無需努力。
但是，您的應用程式越復雜，單元測驗就越有價值。您不想手動測驗整個應用程式以檢查新更改是否不會破壞某些內容。您想確信現有代碼在更改后仍然完好無損，而單元測驗（以及其他型別的測驗）會給您這種信心。
簡而言之，為每個功能多花 1 個小時來撰寫測驗，比在未來花費無數個小時修復意外錯誤要好得多。
uj5u.com熱心網友回復：
這不是一個非常適合回答諸如寬泛問題之類的地方，但我會提供一些提示，您可以使用它們來進一步深入研究測驗及其收益。
有試驗更多的目標，而不是僅僅驗證測驗回傳你郵遞員或者你在除錯器看到驗證了同樣的事情（你也可以寫測驗套件中的郵遞員），在那個時候。
最明顯的特點是下次您更改任何應該或不應該觸及您之前手動驗證的代碼時- 突然間您會得到驗證，舊代碼仍然以與您撰寫時相同的方式作業。行為并沒有因為你這次所做的改變而改變，任何依賴于舊行為的代碼應該仍然有效。除非您有自動化測驗，否則您無法真正確定您最近的更改沒有改變現有行為。
這會創建一個安全網，隨著專案的發展，您可以減少破壞的東西。
擁有可測驗的代碼也會強制分離被測驗介面的關注點（HTTP/介面/類/方法/等）。
這些測驗還可以作為您的 API 應該如何用于新開發人員的簡單檔案，并讓新開發人員對他們對專案的更改更有信心。
撰寫測驗還應該讓您思考“這里的邊緣情況是什么？” 并撰寫測驗來暴露這些邊緣情況并驗證它們是否按預期作業。
當您手動執行代碼時，您仍然會測驗您的代碼，因此不要在完成一段代碼時讓這些知識消失，而是將其形式化為測驗并使其在將來也可用。
撰寫測驗總是會有一點開銷——特別是學習測驗框架、如何測驗以及如何撰寫可測驗的代碼，但與其他所有事情一樣，一旦進入流程，它就會成為第二天性.
uj5u.com熱心網友回復：
在更復雜的專案中，單元測驗將幫助您測驗代碼的每個功能，而無需手動檢查它是否仍在作業。
因此，單元測驗將節省您在郵遞員中手動運行測驗所花費的時間。
uj5u.com熱心網友回復：
咆哮 撰寫好的測驗是困難且耗時。這意味著，它需要熟練的程式員和大量時間。因此，有時很難向任何型別的管理人員解釋無論如何都要這樣做的要求。他們不想長時間在昂貴的人身上花費$$$。
現在關于真正的問題 單元測驗，如果做得好，可以而且應該在每次構建軟體后運行。他們確認曾經有效的方法仍然有效。因此，它可以防止意外更改您不想要的代碼。當然，失敗的單元測驗并不總是意味著麻煩（也許您需要更新測驗），但這絕對意味著某些事情已經發生在您沒有預料到的地方。重復運行一組潛在的大量單元測驗比每次手動進行測驗要便宜得多。您需要除錯東西的時間也會花費您的老板 $$$。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/355983.html
上一篇：洗掉這個具體字串的樣式？