测试驱动开发也称为 TDD。它包括以下要一一遵循的步骤 -
第 1 步 - 创建一个测试。
步骤 2- 验证测试是否失败。
如果测试通过，则创建第二个测试。
如果测试失败，则转到步骤 3。
步骤 3- 修复测试以使其通过。
如果测试通过，则转到步骤 4。
如果测试失败，则跳转到第 3 步。
第 4 步 - 启动代码 refractor 并重做上述所有步骤，直到开发完成。
TDD 的好处
下面列出了 TDD 的好处 -
开发人员需要了解需求以了解场景的结果应该是什么以及如何测试它。
只有当所有测试用例都通过并且代码重构完成时，才完成模块的实现。因此，应在将其移至下一个测试之前完成验证和重构。
重构完成后，将运行单元测试套件。
单元测试可以用作实时文档。
如果发现错误，则会创建测试以获取错误的详细信息。脚本已更新，以通过测试。同时，还会执行其他测试以确保现有功能不会被修复程序破坏。
开发人员可以在测试执行阶段随时参与设计决策并对其进行改进，以确保应用程序正常工作。这样做是为了提高产品的可维护性。
开发人员肯定会进行任何修改。这是因为如果这会影响任何现有功能，则应通过执行测试来反映。这样可以快速解决错误。
在连续运行测试时，所有先前的错误修复也得到验证，并且可以避免类似的错误。
由于主要测试是在开发阶段进行的，因此交付前所需的测试时间很短。
TDD的缺点
下面列出了 TDD 的缺点 -
开发人员发现很难决定何时开始测试。
开发人员对要测试的内容感到困惑。
开发人员不知道是否涵盖了所有必需的规范。
开发人员不确定他们的代码是否增加了业务价值。
围绕 TDD 的神话
下面列出了围绕 TDD 的神话 -
神话——TDD 只关心自动化测试。
事实——TDD 是一种遵循“测试优先”方法的开发技术。
神话——TDD 不包含设计。
事实 - TDD 根据需求进行了彻底的研究和设计。设计是在开发阶段完成的。
神话 – TDD 仅用于单元测试。
事实 - TDD 也用于系统和集成测试。
神话——TDD 不能用于正统的测试项目。
事实 - TDD 用于敏捷开发。但它也可以用于传统的测试项目。
神话——TDD 被认为是一种工具。
事实——TDD 是一种开发技术，在每次新的单元测试通过后，它都会与自动化套件结合在一起，只要代码中有修改和重构后活动就会运行。