測試驅動型開發比QA還要多

概念是，您首先要進行一個測試，描述正在開發的任何軟體功能的一部分功能。 第一次執行該測試應該會導致失敗，因為測試的代碼尚未編寫。 當然，下一步是實施該功能，目標是通過原始測試。 生命週期的第三個步驟(可能是最重要的步驟)是對代碼進行重構。

編寫軟體具有挑戰性，這不僅是因為它的內在品質，而且也是因為它的動態性。 業務需求可能會不斷變化，因此，軟體需求需要能夠適應。 今天編寫的代碼可以滿足當今的需求，但明天或明天一個月後，將會發生一些變化，因此，今天的代碼可能不再是解決特定問題的最佳方法。 通過引入一種比較軟體的機制 是 記錄軟體內容 應該 現在，我們已經擁有了一個強大的工具，它允許我們毫無畏懼地拆解，重寫和重新佈線代碼，以最大程度地滿足當今的要求，因爲我們可以確信，只要我們的所有測試都通過，系統的輸出就應該是相同的。

我們為什麼要使用TDD？

赫爾辛基大學2014年進行的一項審查發現，在許多情況下，TDD在缺陷，質量，復雜性和可維護性方面產生了積極影響，但這些改進可能會以增加開發工作為代價。 這並不是一個令人驚訝的結論，因為編寫額外的測試需要額外的努力，但這種性質的研究似乎忽略了TDD的主要優勢，即反饋。

關閉反饋循環意味著縮短進行變革和學習所需的時間。 你做得越快，你就越靈活。 大多數試圖量化開發生產力的指標都與一段時間內的工作單位有關，並且通過減少接收可操作反饋所需的時間，TDD可以更有效地利用寶貴的資源。 有人說時間就是金錢，所以這裏的經濟效益是不言自明的。 如果您曾經聽說過有人在軟體開發生命週期的環境中提到“左班”，這正是他們所指的。

為您的應用程式安裝測試套件的另一個好處是您可以將其自動化。 開發人員不僅可以將這些測試作為開發生命週期的一部分來執行，而且還可以由其他係統作為煙霧測試或CI/CD管道的一部分來執行。 通過自動化向市場交付代碼的步驟，它可以更快地交付整個產品，從而加快您從用戶那裡收到的反饋，然後可以解釋這些反饋並應用到下一次迭代中。

這兩點的協同效應是顯而易見的：由於代碼庫使開發人員能夠根據業務需求不斷調整代碼庫，而企業能夠快速徵求客戶的反饋，因此形成了一個系統，使團隊能夠以更少的工作量實現更多的價值。

充分利用TDD

測試驅動型開發只是測試軟體的許多不同方法之一。 無論您選擇如何實施它，重要的部分是它為您的組織帶來價值。 與任何其他學科一樣，您應該完全根據組織的需求自由使用，根據自己的需要進行調整或完全不使用。 儘管如此，如果你確實選擇走TDD路，正如先知克拉普頓預言：“這是你使用它的方式。”

與任何其他工具一樣，TDD的有效性和價值取決於其執行。 在軟體開發中，各種工具或技術往往被轉化為替罪羊來解釋項目的失敗或缺點，但卻是一個糟糕的手藝人將他的工具歸咎於他。 因此，讓我們重點關注如何充分利用TDD。

文化重構

TDD的最後一個也是最重要的步驟是重構代碼，但要使TDD正常工作，這可能不是唯一需要進行的重構。 如果您選擇實施某種形式的測試驅動型開發，那麼周圍的文化也必須適應以支援這種發展理念。

對於TDD，最常見的失敗往往是，編寫測試，通過測試，然後重構的連續週期從未實際完成，而是跳過重構步驟而導致短路。 問題往往不是TDD或任何其他特定技術，而是軟體開發的文化。

與文檔記錄不同，重構似乎是在截止日期或預算限制時首當其衝的事情之一，因為畢竟，必須有人寫下所有這些測試。 因此，在緊湊的時間裡，測試和文檔以及任何不被認為是關鍵任務的東西都會被放棄。 隨之而來的是代碼庫的總體質量穩步下降，而技術債務的積累則逐漸減少。

重構是該過程中的一個步驟，它致力於將簡單工作的代碼轉換爲更乾淨，更易於維護的代碼庫。 它使開發人員能夠後退一步，識別整個系統中的模式，並就如何調整這些模式以使其更具通用性或識別新興的反模式並採取措施緩解這些模式作出更明智的決策。 這甚至可能是識別何時需要將整個架構拆分為獨立微服務或任何其他潛在改進之間的區別。 沒有這一步，您可能會錯失自我反省和漸進改進的機會，最終您的代碼庫將面臨逐漸(或不)轉變為一個大的泥漿球的風險。