Home Blogs 測試驅動型開發比QA更重要
Applications

About The Author

Outline

軟體領域中的許多人(如果不是大多數)將 測試驅動型開發 (TDD)狹義地看作是軟體開發的獨特過程。 許多討論和辯論都圍繞着使用特定工具或技術,這些工具或技術旨在根據預定義的要求列表來執行代碼的每個角落,目的是證明給定的代碼庫按描述的方式執行。 因爲經常發生,所以很難將信號與噪音和原則與實踐區分開來,因此我們在實施細節中失去了,而忽略了原來的意圖。 因此,讓我們後退一步,重新考慮圍繞”測試驅動型發展”的對話:具體而言,它是什麼,以及它如何幫助您的企業?

什麼是TDD?

在企業環境中,軟體的目的是爲企業增加價值。 因此,任何開發工作的主要挑戰之一是將業務需求和目標映射到相應的系統要求。 接下來的問題是:如何編寫軟體來滿足這些要求,以及隨着項目及其代碼庫的增長,如何確保您的軟體 繼續 滿足這些要求

進入測試驅動型開發。

測試驅動型開發(TDD)是一種組織方法,通過編寫描述和練習軟體的測試來編寫軟體。 TDD的核心是重複三個步驟:編寫失敗的測試,通過測試,重構。

概念是,您從測試開始,該測試描述了正在開發的任何軟體功能的一部分。 第一次執行該測試會導致失敗,因爲正在測試的代碼尚未編寫。 當然,下一步是實施該功能,目的是使原始測試通過。 生命週期中的第三步,也可以說是最重要的一步,就是重新構建代碼。

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

我們爲什麼要使用TDD?

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

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

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

這兩點的協同效應是明確的: 藉助代碼庫,開發人員能夠不斷地根據業務需求調整代碼庫,以及企業能夠快速徵求客戶反饋的能力,最終形成了一個系統,使團隊能夠從較少的工作中獲得更多價值。

充分利用TDD

測試驅動型開發只是測試軟體的許多不同方法之一。 無論您選擇如何實施它,重要的部分是它爲您的組織提供了價值。 與任何其他學科一樣,您應該完全根據組織的需求自由使用,根據您認爲合適的方式進行調整,或根本不使用。 話雖如此,如果你選擇走TDD路徑,正如先知克拉普頓所預言的那樣:“這是你使用它的方式。”

與任何其他工具一樣,TDD的有效性和價值取決於其實施。 在軟體開發過程中,各種工具或技術往往被轉化爲替罪羊來解釋項目的失敗或缺點,但指責他的工具是一個可憐的工匠。 因此,讓我們集中討論如何充分利用TDD。

文化重構

TDD的最後一個也是最重要的步驟 是重構代碼,但TDD的工作可能不是唯一需要重構的。 如果您選擇實施某種形式的”測試驅動型發展”,則周圍的文化也必須適應這種發展理念。

在TDD的情況下,最常見的失敗往往是連續的寫入測試週期,使測試通過,然後重構從未真正完成,而是通過重構步驟而短路。 通常,問題不是TDD或任何其他特定技術,而是軟體開發的文化。

與文檔不同,重構似乎是在截止日期或預算嚴格時拋出的第一件事,因爲畢竟, 有人 必須寫所有這些測試。 因此,在危機期間,測試和文檔以及不被認爲是關鍵任務的任何其他內容都會被淘汰。 隨之而來的是,代碼庫的總體質量穩步下降,技術債務的積累也逐漸減少。

重構是該過程中的步驟,它努力將簡單的代碼轉換爲更清潔和更易於維護的代碼庫。 開發人員可以在這一方面後退一步,識別整個系統中的模式,並就如何調整這些模式以使其更具多樣性或識別新出現的反模式並採取措施來緩解這些模式做出更明智的決策。 它甚至可能是識別何時需要將整個體系結構劃分爲獨立微服務或任何其他潛在改進的區別。 如果沒有這個步驟,你可能會錯過反思和漸進改進的機會,最終你的代碼庫有可能逐漸(或不)轉變爲 一大堆泥球。

爲了獲得測試驅動型發展的好處,文化必須長期看待整個過程及其潛力,並投入時間來應用完整的“紅色,綠色,重構”週期,而不僅僅是權宜之計。

閃亮的新玩具

在整個系統設計方面,通常花費太多時間來規劃系統的細節,而不實際編寫任何代碼。 “綠色領域”項目可能會令人興奮,因爲它具有與一張乾淨紙張相關的所有預期潛力。 工程師和建築師都會成爲嘗試這種技術的受害者,他們主張使用一種當月的味道技術,忽視任何警告信號,這種技術可能不適合這個特定項目,而傾向於嘗試新的或酷的東西。 快進幾個月,框架du-jour不再滿足團隊的需要,代碼的質量也在下降,我們回到了技術成爲項目結果不佳的替罪羊的部分。

在一天結束時,重要的是用於促進TDD的技術,方法或框架爲團隊和業務工作。 如果您被工具束縛,他們不僅 不會增加 價值,而且還在積極地反對您。 仔細評估您打算使用的任何框架,並花時間準確瞭解您將如何使用它。 這種方法適用於所有設計決策,而不僅僅是與TDD相關的決策!

總結

簡而言之,像TDD這樣的想法是提供一個框架,以更方便的方式收集反饋,而不僅僅是一種防止代碼庫中出現錯誤的技術。 無論您選擇哪種方法,關鍵都應該是使您的企業及其軟體能夠更快地適應不斷變化的趨勢和業務需求。 在此過程中,請注意,TDD及其對應方並不只是您可以要求開發團隊實施而忘記的事情, 爲了有效地利用這些技術,必須在深入瞭解框架和工具等實施細節之前,在文化層面上採取並啓用這種方法。