tdd 單元測試

最近，我一直在寫與自動測試有關的更高級的概念（主要與Spock有關）。 但是，在進行測試培訓時，我清楚地看到，通常對特定工具的知識并不是主要問題。 即使使用Spock，也可以編寫腫且難以維護的測試，從而破壞（或不了解）與編寫單元測試有關的良好實踐。 因此，我決定寫一些更基本的東西來促進它們，并且在指導經驗不足的同事時準備使用一些參考材料。

介紹

編寫良好的單元測試應滿足幾個要求，這是整個系列的主題。 在這篇博客文章中，我想提出一個相當成熟的概念，即將單元測試劃分為具有嚴格定義的功能的3個單獨的塊（依次是行為驅動開發的子集）。

單元測試通常集中于測試給定單元（通常是一個給定類）的某些特定行為。 與通過UI執行的驗收測試相反，在每個測試中都將存根/模擬作為其協作者，從零開始設置一個要測試的類（測試中的類）比較便宜（快速）。 因此，性能應該不是問題。

樣品測試

為了演示規則，我將使用一個小示例。 ShipDictionary是一個類，提供根據特定條件（按名稱的一部分，生產年份等）搜索太空船的功能。 該詞典由不同的船舶索引（在役，退役，在生產等中的船舶）提供動力。 在那個特定的測試中，它被測試了按其名稱的一部分搜索飛船的能力。

private static final String ENTERPRISE_D = "USS Enterprise (NCC-1701-D)";@Test public void shouldFindOwnShipByName() { //given ShipDatabase shipDatabase = new ShipDatabase(ownShipIndex, enemyShipIndex); given(ownShipIndex.findByName("Enterprise")).willReturn(singletonList(ENTERPRISE_D)); //when List foundShips = shipDatabase.findByName("Enterprise"); //then assertThat(foundShips).contains(ENTERPRISE_D); }

給定時間

測試驅動開發方法和行為驅動開發方法中都存在的良好習慣是“先驗”知識，它將在特定測試用例中進行測試（認定）。 可以以更正式的方式（例如，用Cucumber/小Cucumber編寫的用于驗收測試的方案）或以自由形式（例如，特別注意的要點或只是下一步應該做什么的想法）來完成。 有了這些知識，就很容易確定整個測試將組成的三個關鍵部分（分開的部分）。

給定–準備

在單元測試的第一部分（稱為given ）中，需要創建一個實際對象實例，在該對象實例上將執行測試的操作。 在有重點的單元測試中，僅放置一類要測試的邏輯。 另外，執行測試所需的其他對象（稱為協作者）應初始化為存根/模擬，并適當存根（如果需要）。 還必須將所有協作者注入到要測試的對象中，該對象通常與該對象創建結合在一起（因為構造函數注入應該是依賴注入的首選技術）。

//given ShipDatabase shipDatabase = new ShipDatabase(ownShipIndex, enemyShipIndex); given(ownShipIndex.findByName("Enterprise")).willReturn(singletonList(ENTERPRISE_D));

何時–執行

在when部分中，將執行要測試的操作。 在我們的情況下，這是一個搜索請求，然后將結果存儲在變量中以供進一步聲明。

//when List foundShips = shipDatabase.findByName("Enterprise");

在大多數情況下，在該部分中僅執行一項操作是一件好事。 更多的元素可能表明嘗試測試多個操作（可能）可以分為多個測試。

然后–斷言

-最后一節的責任， then -主要是先前接收到的結果的斷言。 它應該等于期望值。

//then assertThat(foundShips).contains(ENTERPRISE_D);

此外，可能有必要對聲明的模擬執行方法執行的驗證。 這不應該是一種常見的做法，因為在大多數情況下，對接收值的聲明足以確認所測試的代碼能夠按預期工作（根據設置的邊界）。 但是，特別是對于測試void方法，需要驗證是否已使用預期參數執行了特定方法。

AAA aka 3A –一種替代語法

正如我已經提到的，BDD是一個更廣泛的概念，它對于編寫具有預先定義的需求（通常是非技術形式）的功能/驗收測試特別方便。 一種替代的測試劃分語法（對于各節而言，含義非常相似）是“ 配置行為聲明”，通常縮寫為AAA或3A。 如果您根本不使用BDD，并且三個字母比GWT更容易記住，那么使用它來創建相同的高質量單元測試就很好。

調整與優化

將實用工具和方法學與持續進行的技能獲取過程（也稱為Dreyfus模型 ）進行匹配的過程已在《 實用思維與學習：重構您的濕軟件 》一書中進行了很好的描述。 當然，在許多情況下，使用given節移至setup/init/before節或內聯初始化的測試的簡化變體可能很方便。 同樣可以適用于when和then部分，其可以被合并在一起（成expect部分，特別是在參數化測試）。 具有編寫單元測試的經驗和流利性，使用速記和優化（尤其是測試一些非平凡的案例）是完全有效的。 只要整個團隊都了解約定，并且能夠記住有關編寫好的單元測試的基本假設。

摘要

根據我在軟件開發方面的經驗以及作為一名培訓師，我清楚地看到，將（單元）測試劃分為多個部分可以使它們更短，更易理解，尤其是團隊中經驗不足的人員。 與明確找出并立即將所有內容寫入測試中相比，用明確定義的責任來填充3個部分更容易。 最后，特別是對于僅閱讀本文第一部分和最后部分的人們，此處遵循以下簡明規則：

• given –測試中的對象初始化+存根/模擬的創建，存根和注入
• when –在給定測試中進行測試的操作
• then –收到結果聲明+模擬驗證（如果需要）

PS最好在IDE中設置一個測試模板，以保護編寫每個測試所需的許多擊鍵。
PSS，您發現本文很有用，您可以讓我知道，以鼓勵我將來寫更多有關單元測試的基礎知識。

圖片來源：Tomas Sobek，Openclipart， https ：//openclipart.org/detail/242959/old-scroll

自我提升 。 您想快速有效地提高您和您的團隊的測試技能以及對Spock / JUnit / Mockito / AssertJ的了解嗎？ 我進行了濃縮（單元） 測試培訓 ，您可能會覺得有用。

翻譯自: https://www.javacodegeeks.com/2017/05/importance-given-unit-tests-tdd.html

tdd 單元測試

總結

以上是生活随笔為你收集整理的tdd 单元测试_何时给定在单元测试和TDD中的重要性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。