tdd java_Java TDD简介

tdd java_Java TDD简介–第1部分

tdd java

欢迎来到测试驱动开发 （TDD）系列的介绍。我们将在TDD上下文中讨论Java和JUnit ，但这只是工具。本文的主要目的是使您全面了解TDD，而无论使用哪种编程语言和测试框架。

如果您在项目中不使用TDD，那么您要么是懒惰的，要么就是根本不知道TDD是如何工作的。关于缺乏时间的借口不适用于这里。

关于这篇文章

在这篇文章中，我将解释什么是TDD以及如何在Java中使用它。在TDD中，单元测试在哪个地方进行？单元测试必须涵盖的内容。最后，您需要遵循哪些原则才能编写良好而有效的单元测试。

如果您已经了解Java中有关TDD的所有知识，但是对示例和教程感兴趣，那么我建议您跳过本部分，继续进行下一部分（它将在这一部分发布后的一周内发布）。

什么是TDD？

如果有人要我用几句话来解释TDD，那么我说TDD是功能实现之前的测试开发。您可以争辩：很难测试尚不存在的事物。肯特·贝克（Kent Beck）可能会为此给你一巴掌。

那怎么可能呢？可以通过以下步骤进行描述：

1.您阅读并了解特定功能的要求。
2.您开发了一组测试功能的测试。由于缺少功能实现，所有测试均为红色。
3.开发功能，直到所有测试变为绿色。 4.重构代码。

BDD流

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美元。

最后应该对单元测试进行细化。在每个测试中放置一个逻辑场景时，您可以从测试中获得信息丰富的反馈。并且在发生单个故障的情况下，您不会丢失有关其余功能的信息。

单元测试原理