Java TDD简介–第1部分
歡迎來到測試驅動開發 （TDD）系列的介紹。 我們將在TDD上下文中討論Java和JUnit ，但這只是工具。 本文的主要目的是使您全面了解TDD，而無論使用哪種編程語言和測試框架。
如果您在項目中不使用TDD，那么您要么很懶，要么就是根本不知道TDD的工作方式。 關于缺乏時間的借口不適用于這里。
關于這篇文章
在這篇文章中，我將解釋什么是TDD以及如何在Java中使用它。 在TDD中，單元測試應放在哪個位置。 單元測試必須涵蓋的內容。 最后，為了編寫良好而有效的單元測試，需要遵循哪些原則。
如果您已經了解Java中有關TDD的所有知識，但是對示例和教程感興趣，那么我建議您跳過這一部分，繼續下一部分（它將在這一部分發布后的一周內發布）。
什么是TDD？
如果有人要我用幾句話來解釋TDD，那么我說TDD是功能實現之前的測試開發。 您可以爭辯：很難測試尚不存在的事物。 肯特·貝克（Kent Beck）可能會為此一巴掌。
那怎么可能呢？ 可以通過以下步驟進行描述：
1.閱讀并了解特定功能的要求。
2.您開發了一組測試功能的測試。 由于沒有功能實施，所有測試均為紅色。
3.開發功能，直到所有測試變為綠色。 4.重構代碼。
TDD需要不同的思維方式，因此，為了根據它開始工作，您需要忘記以前開發代碼的方式。 這個過程很難。 如果您不知道如何編寫單元測試，那就更難了。 但這是值得的。
使用TDD進行開發具有寶貴的優勢：
1.您對實現的功能有更好的了解。
2.您具有功能完整性的可靠指標。
3.代碼包含測試，并且被修復或新功能破壞的可能性較小。
這些優勢的代價是很高的–與切換到新的開發方式有關的不便以及您花費在開發每個新功能上的時間。 這是質量的代價。
這就是TDD的工作方式–編寫紅色的單元測試，開始實現功能，使測試變為綠色，執行代碼重構。
TDD中單元測試的位置
由于單元測試是測試自動化金字塔中最小的元素，因此TDD基于它們。 借助單元測試，我們可以檢查任何類的業務邏輯。 如果您知道如何做，則編寫單元測試很容易。 那么，您需要使用單元測試進行測試的內容以及該怎么做呢？ 您知道這些問題的答案嗎？ 我將嘗試以簡潔的形式說明答案。
單元測試應盡可能小。 不，不不要考慮這一點，因為一項測試僅適用于一種方法。 當然，這種情況也是可能的。 但通常，一個單元測試意味著調用多種方法。 這稱為行為測試。
讓我們考慮Account類：
public class Account {private String id = RandomStringUtils.randomAlphanumeric(6);private boolean status;private String zone;private BigDecimal amount;public Account() {status = true;zone = Zone.ZONE_1.name();amount = createBigDecimal(0.00);}public Account(boolean status, Zone zone, double amount) {this.status = status;this.zone = zone.name();this.amount = createBigDecimal(amount);}public enum Zone {ZONE_1, ZONE_2, ZONE_3}public static BigDecimal createBigDecimal(double total) {return new BigDecimal(total).setScale(2, BigDecimal.ROUND_HALF_UP);}@Overridepublic String toString() {StringBuilder sb = new StringBuilder();sb.append("id: ").append(getId()).append("\nstatus: ").append(getStatus()).append("\nzone: ").append(getZone()).append("\namount: ").append(getAmount());return sb.toString();}public String getId() {return id;}public boolean getStatus() {return status;}public void setStatus(boolean status) {this.status = status;}public String getZone() {return zone;}public void setZone(String zone) {this.zone = zone;}public BigDecimal getAmount() {return amount;}public void setAmount(BigDecimal amount) {if (amount.signum() < 0)throw new IllegalArgumentException("The amount does not accept negative values");this.amount = amount;} }該類中有4種getter方法。 要特別注意它們。 如果我們為每個getter方法創建一個單獨的單元測試，則會得到太多的冗余代碼行。 可以通過行為測試來處理這種情況。 想象一下，我們需要使用其構造函數之一來測試對象創建的正確性。 如何檢查對象是否按預期創建？ 我們需要檢查每個字段的值。 因此，可以在這種情況下使用吸氣劑。
創建小型快速的單元測試 ，因為它們應在每次提交到git存儲庫并將新的構建提交到服務器之前執行。 您可以考慮一個帶有實數的示例，以了解單元測試速度的重要性。 假設一個項目有1000個單元測試。 他們每個人都需要100毫秒。 結果，所有測試的運行需要1分40秒。
實際上100ms對于單元測試來說太長了，因此您必須通過應用不同的規則和技術來減少運行時間，例如，不要在單元測試中執行數據庫連接（根據定義，單元測試是隔離的）或在其中執行昂貴的對象的初始化。 @Before塊。
為單元測試選擇好名字 。 測試的名稱可以是您想要的任何名稱，但是它應該代表測試進行的驗證。 例如，如果我需要測試Account類的默認構造函數，則將其命名為defaultConstructorTest 。 選擇測試名稱的另一個有用建議是在命名測試之前編寫測試邏輯。 在開發測試時，您會了解其中發生的情況，因此名稱的組成變得更加容易。
單元測試應該是可預測的 。 這是最明顯的要求。 我將在示例中進行解釋。 為了檢查轉帳操作（需支付5％的費用），您必須知道發送的金額以及輸出的金額。 此測試方案可以實現為發送100美元和接收95美元。
最后應該對單元測試進行細化 。 在每個測試中放置一個邏輯場景時，您可以從測試中獲得有用的反饋。 并且在發生單個故障的情況下，您不會丟失有關其余功能的信息。
所有這些建議旨在改進單元測試設計。 但是，您還需要了解一件事-測試設計技術的基礎知識。
測試設計技術基礎
沒有測試數據就不可能編寫測試。 例如，當您測試匯款系統時，可以在匯款字段中設置一些金額。 在這種情況下，數量是測試數據。 那么您應該選擇哪些值進行測試？ 為了回答這個問題，我們需要經歷最流行的測試設計技術。 測試設計技術的通用目的是簡化測試數據的構成。
首先，讓我們假設我們可以發送正整數的錢。 同樣，我們發送的郵件不能超過1000。這可以表示為：
0 < amount <= 1000; amount in integer我們所有的測試場景可以分為兩組：正面和負面場景。 第一個用于系統允許的測試數據，并導致成功的結果。 第二種是所謂的“故障場景”，當我們使用不適當的數據與系統進行交互時。
根據等價技術的類別，我們可以從（0; 1000]范圍內選擇一個隨機整數。設為500。由于系統適用于500，因此對于該范圍內的所有整數均適用。有效值，也可以從范圍中選擇無效的輸入，可以是任何帶浮點的數字，例如125.50
然后我們必須參考邊界測試技術 。 根據它，我們必須從范圍的左側和右側選擇2個有效值。 在我們的例子中，我們以1為允許的最小正整數，從右邊取1000。
下一步是在邊界上選擇2個無效值。 所以它是0和1001
因此，最后我們有6個值需要在單元測試中使用：
- （1，500，1000）–對于積極的情況
- （0，125.50，1001）–否定情況
摘要
在這篇文章中，我試圖解釋TDD的各個方面，并說明在TDD中單元測試的重要性。 因此，我希望經過如此詳盡和長期的bla-bla理論，我們可以繼續實踐。 在下一篇文章中，我將演示如何在功能之前開發測試。 我們將從文檔分析開始，到代碼重構結束，逐步進行操作。
確保所有測試都是綠色的:)
翻譯自: https://www.javacodegeeks.com/2015/11/introduction-in-java-tdd-part-1.html
總結
以上是生活随笔為你收集整理的Java TDD简介–第1部分的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 信达天御备案名（信达天御备案）
- 下一篇： 用Java测试多线程代码