＃TDD

在我擔任軟體開發人員期間，我曾在使用"測試驅動開發"（TDD）的環境中工作。享受它是一回事（我曾經做過），積極鼓勵人們參與提高工作質量和可維護性的過程是另一回事。

如果您正在尋找可能與之合作或合作的公司，那麼他們的軟體開發流程便是它們實施方法的良好程度的一種指標，這種方法使他們的生活更輕鬆。當被問到有關TDD的問題時，對受訪者來說是一個紅燈，但是訪問者對這在實踐中的含義只有一個不穩定的想法。

紅綠重構

TDD過程涉及在編寫代碼之前編寫單元測試。對於開發人員來說，這意味著您必須在編寫任何特定算法來解決問題之前就知道代碼的行為。

TDD流程的部分價值在於，必須先了解代碼規範，然後才能開始對該代碼進行工作。

編寫測試後，進入一個循環以創建可用於生產的代碼，該代碼遵循下圖中的流程：

請注意，TDD流程不會阻止您重構代碼並最大化將投入生產的代碼的效率。它也不會排除通常的代碼審查過程，甚至可以說您可以隨時隨地審查自己的代碼（通過良好的質量測試，可以清楚地知道您的代碼是否具有適當的質量）。

TDD的優勢

在代碼之前編寫測試的要求意味著在編寫代碼之前，必須確定任何特定單元的規範。因此，隨著軟體的開發，整個軟體的需求將得到確認。

測試和重構被納入到流程中，從定義上講，這鼓勵了嚴格的質量代碼生產。

單元測試本身鼓勵代碼庫中的模塊化，而TDD則有助於生成具有良好測試覆蓋率的，經過良好測試的代碼。

TDD流程應該節省維護時間，因為缺陷應該易於發現並且可以在開發過程的早期發現（快速生產失敗的方法）。

當開發人員參與測試而不僅僅是將工作交給測試黑匣子時，他們更有可能參與該過程，並且比其他人更認真地對待測試。

TDD的缺點

理想情況下，整個公司或組織都需要支持TDD的實施才能成功。在編寫代碼之前先編寫測試意味著在開始編寫解決方案代碼之前，我們需要了解軟體的要求和代碼的規範。

問問自己：

是否已為TDD建立業務？

TDD可以（當然也可以在軟體項目的早期階段）花費更長的時間進行編碼，並且其中的某些優勢僅在軟體開發過程的維護部分才能看到。一些經理希望看到現在編寫的代碼，並在（如果有的話）出現時承擔不良的開發過程的後續後果。

所有代碼都應該是模塊化的，這使得實現可測試代碼更加容易。但是，我們都從事過由於某種原因而無法很好實施的軟體項目，並且可能需要加入一個已經通過一些不穩定的開發實踐的特定項目，因為它接近完成。

我們可能會被問到自己：

我們如何在非模塊化代碼庫中輕鬆實現TDD？

我已經寫了幾篇有關模擬和依賴注入的文章，因為這是初級開發人員可能會遇到的問題。圍繞存根和嘲弄發展技能可能需要一些時間，這是團隊意識到並準備的嗎？

這把我們帶到了重要的一點。組織中的每個人都在嗎？是否有開發人員認為他們編寫了完美的代碼（我想我之前曾與該開發人員合作；他們的代碼很糟糕）而拒絕實施TDD流程？如何使員工參與進來，並鼓勵他們指向同一個方向才能做出出色的工作？

結論

TDD的優缺點實際上看起來相當平衡。但是，更深入地了解，您會發現平衡是在軟體質量上，一個團隊在軟體開發的早期就對此進行了投資，而不是在相當長的周期結束後進行維護。

如果您可以在組織內開發TDD，那麼如果您有能力的員工，這似乎是一個普通的"沒腦子"。這並不是說對每個組織都適用（事實並非如此），但是您需要在了解組織和編程環境的情況下做出自己的選擇。

(本文翻譯自Steven Curtis的文章《Test Driven Development (TDD): The Advantages and Disadvantages》，參考：https://medium.com/@stevenpcurtis.sc/test-driven-development-tdd-the-advantages-and-disadvantages-5347899ead90)