什么是测试驱动的 Development(TDD) ？
测试驱动开发(TDD)是一种软件开发方法，其中开发测试用例以指定和验证代码将做什么。简而言之，首先创建和测试每个功能的测试用例，如果测试失败，则编写新代码以通过测试，并使代码简单且无错误。
测试驱动开发从为应用程序的每一个小功能设计和开发测试开始。TDD的完整形式是测试驱动的开发。
TDD的简单概念是在编写新代码之前(在开发之前)编写并更正失败的测试。(测试只不过是我们需要测试才能满足的需求条件)。
测试驱动开发是在实际开发应用程序之前开发和运行自动化测试的过程。因此，TDD有时也称为测试优先开发。
在本教程中，将了解更多关于-
- 如何进行TDD测试
- TDD vs.传统测试
- 什么是验收TDD和开发者TDD
- 通过敏捷模型驱动开发(AMDD)扩展TDD
- 测试驱动开发(TDD)vs.敏捷模型驱动开发(AMDD)
- TDD示例
- TDD的好处
如何进行TDD测试
以下步骤定义如何执行TDD测试，
- 添加测试。
- 运行所有测试，查看是否有新的测试失败。
- 编写一些代码。
- 运行测试并重构代码。
- 重复一遍。
测试驱动开发的五个步骤
TDD周期定义
- 写测试用例
- 让它跑起来
- 更改代码以使其正确，即重构。
- 重复该过程。
关于TDD的一些澄清：
- TDD方法既不是关于“测试”的，也不是关于“设计”的。
- TDD并不意味着“编写一些测试，然后构建一个通过测试的系统。
- TDD并不意味着“做很多测试”。
TDD vs.传统测试
下面是测试驱动开发与传统测试之间的主要区别：
TDD方法主要是一种规范技术。它确保源代码在确认性级别经过彻底测试。
- 使用传统测试，成功的测试会发现一个或多个缺陷。当测试失败时，已经取得了进展，因知道需要解决问题。
- TDD可确保系统实际满足为其定义的要求。它有助于建立对系统的信心。
- 在TDD中，更多的注意力放在验证测试是否正常工作的生产代码上。测试是否会显示应用程序的正确/不正确执行以满足要求。
- 在TDD中，可以实现100%的覆盖率测试。与传统测试不同，每一行代码都要进行测试。
- 传统测试与TDD的结合导致了系统测试的重要性，而不是系统的完美性。
- 在敏捷建模(AM)中，应该“有目的地进行测试”。应该知道为什么要测试某个东西，以及它需要测试的级别。
测试TDD和开发TDD
TDD有两个级别
- 测试TDD(ATDD)：使用ATDD，可以编写单个验收测试。此测试满足要求，也称为行为驱动开发(BDD)。
- 开发人员TDD：使用开发人员TDD，可以编写单个开发人员测试，也就是说，这样可以提高效率。
通过敏捷模型驱动开发(AMDD)扩展TDD
TDD非常擅长详细的规范和验证。能通过AMDD解决TDD无法解决的敏捷扩展问题。 因此，AMDD被用于更大的问题。
AMDD的生命周期
在模型驱动开发(MDD)中，在编写源代码之前创建大量的模型。这反过来又有一种灵活的方法？
在上图中，每个框代表一个开发活动。
设想是预测/想象测试的TDD过程之一，将在项目的第一周执行。高级需求和体系结构建模是为了成功设想而进行的。 不是对软件/系统进行详细的规范，而是探索软件/系统的需求，它定义了项目的总体策略。
迭代0：展望
有两个主要的子激活。
- 初始需求预想。识别高级求可能需要几天时间主要关注的是探索使用模型、初始域模型和用户界面模型(UI)。
- 最初的设想。这也需要几天的时间来确定，主要的焦点是探索技术图、用户界面(UI)流、域模型和变更案例。
迭代建模
在这里，团队必须计划将为每个迭代所做的工作。
- 敏捷流程用于每个迭代，也就是说，在每个迭代期间，将优先添加新的工作项。
- 首先，将考虑优先级更高的工作。添加的工作项可以随时重新排列优先级或从项堆栈中删除。
- 团队讨论他们将如何实现每个需求。建模用于此目的。
- 对要在该迭代中实现的每个需求进行建模、分析和设计。
模型风暴
这也称为即时建模。
- 在这里，建模会议涉及一个由2/3成员组成的团队，他们在纸上或白板上讨论问题。
- 一名团队成员会另一名成员与他们一起建模。团队成员聚集在一起共享白板/白纸的模式。
- 他们不断探索问题，直到找不到问题的主要原因。及时地，如果一个团队成员确定了他/她想要解决的问题，那么他/她会迅速得到其他团队成员的帮助。
- 其他小组成员然后探讨这个问题，然后每个人都像以前一样继续下去。它也称为站立建模或客户QA会议。
测试驱动开发(TDD)
- 它促进了应用程序代码和详细规范的验证性测试。
- 验收测试(详细需求)和开发人员测试(单元测试)都是TDD的输入。
- TDD使代码更简单、更清晰。它允许开发人员维护较少的文档。
评论
- 是可选的.包括代码检查和模型审查。
- 可以针对每个迭代或整个项目进行。
- 是为项目提供反馈的一个很好的选择。
测试驱动开发(TDD)vs.敏捷模型驱动开发(AMDD)
| TDD | AMDD |
|---|---|
| TDD缩短了编程反馈环路 | AMDD缩短了建模反馈环路。 |
| TDD是详细的规范 | AMDD适用于更大的问题 |
| TDD促进高质量代码的开发 | AMDD促进了与利益相关者和开发人员的高质量沟通。 |
| TDD与程序员对话 | AMDD与业务分析师、利益相关者和数据专业人员交谈。 |
| TDD非视觉导向 | AMDD以视觉为导向 |
| 拓展署的工作范围有限，只限于软件工程。 | AMDD的范围很广，包括利益相关者。它涉及到努力达成共识。 |
| 两者都支持进化式开发 |
现在，通过示例学习测试驱动开发。
TDD示例
在这个测试驱动开发示例中，将定义一个类密码。对于这门课，我们将努力满足以下条件。
接受密码的条件：
- 密码应在5到10个字符之间。
首先，在此TDD示例中，我们编写满足上述所有要求的代码。
场景1：要运行测试，创建类PasswordValidator()；
将在TestPassword()类之上运行；
输出传递如下所示；
输出：
场景2：在这里我们可以看到，在方法TestPasswordLength()中，不需要创建PasswordValidator类的实例。实例表示创建类的对象来引用该类的成员(变量/方法)。
从代码中删除PasswordValidator PV=new PasswordValidator()。(见下图)
因此，我们重构(更改代码)如下：
场景3：重构后，输出显示失败状态(见下图)，这是因为我们删除了实例。因此没有引用非静态方法isValid()。
因此，我们需要更改此方法，在布尔值之前添加“静态”字，作为公共静态布尔值isValid(字符串密码)。重构类PasswordValidator()以移除上述错误以通过测试。
输出：
在对类PassValidator()进行更改之后，如果我们运行测试，则输出将按如下所示传递。
TDD的优势
以下是软件工程中测试驱动开发的主要优势：
- 提前通知错误。
- 开发人员测试他们的代码，但在数据库世界中，这通常由手动测试或一次性脚本组成。使用TDD，随着时间的推移，可以构建一套和任何其他开发人员都可以随意重新运行的自动化测试。
- 设计更好、更干净、更具可扩展性的代码。
- 有助于理解代码将如何使用以及它如何与其他模块交互。
- 会带来更好的设计决策和更好的代码可维护性。
- TDD允许编写具有单一职责的较小代码，而不是具有多个职责的单一过程。这使得代码更容易理解。
- TDD还强制只编写生产代码以通过基于用户需求的测试。
- 对重构的信心
- 如果重构代码，代码中可能会出现中断。因此，如果在使用自动测试时发现中断，则会给出适当的警告。
- 使用TDD，应该会产生更快、更具可扩展性的代码，错误更少，更新风险最小。
- 有利于团队合作
- 在没有任何团队成员的情况下，其他团队成员可以很容易地拿起并处理代码。它还有助于知识共享，从而使团队的整体效率更高。
- 对开发人员有好处
- 虽然开发人员必须花费更多的时间来编写TDD测试用例，但调试和开发新功能所需的时间要少得多。将编写更干净、更简单的代码。
总结：
- TDD代表测试驱动开发。
- TDD含义：它是修改代码以通过先前设计的测试的过程。
- 它更强调产品代码，而不是测试用例设计。
- 测试驱动开发是修改代码以通过先前设计的测试的过程。
- 在软件工程中，它有时被称为“测试优先开发”。
- TDD测试包括重构代码，即在不影响代码行为的情况下更改/向现有代码添加一定数量的代码。
- TDD编程使用时，代码变得更加清晰和易于理解。
