什么是测试驱动开发（TDD）？
自从我的软件工程之旅开始以来，我的脑海中就没有几个关键问题，特别是关于测试策略
- 我是否编写了足够的测试，我的测试套件是否完全适合所有用户场景？
- 我是否在编写高质量的测试，我的测试套件是否正确模拟了我的应用程序？
- 其中最大的一个， 我只是想让我的测试套件通过吗？
让我详细说明最后一点，在传统设置中，当我们先编写代码然后对其进行测试时，其想法只是将一些测试与新编写的代码相关联。我的测试策略过去是由代码驱动的，例如在单元测试中，所有的模拟对象、服务、数据集、断言都像我的代码一样编写。本质上，代码被认为优于测试。
我需要考虑功能/代码和测试套件以及单独的实体来改变这种方法，然后我遇到了 测试驱动开发（TDD）。
什么是 TDD？
根据维基百科 , 测试驱动开发 ( TDD ) 是一个软件开发过程，依赖于在软件完全开发之前将软件需求转换为测试用例，并通过针对所有测试用例重复测试软件来跟踪所有软件开发。这与首先开发软件和稍后创建测试用例相反。
简单来说，TDD 是一种软件开发策略，其中应用程序中的每个新功能都由为其编写的测试用例套件驱动。测试套件是在实际功能之前编写的，它不仅确保了代码的正确性，而且间接地发展了应用程序的设计和架构。
实施 TDD：红绿重构周期
让我们考虑一个简单的例子，一个新的特性来实现对输入字段的验证，其中某些字符集是不允许的
第 1 步：在这个阶段它会失败——RED
在这一步中，我们将针对我们即将实现的用户场景编写一个测试套件，在这一阶段，我们将编写一个测试套件，考虑到与它对应的生产代码已经存在。
果然测试失败了：
第 2 步：代码可能很难看，但它可以工作！ - 绿色
在这个阶段，我们将编写一个简单的解决方案，使测试通过，我们被允许违反最佳实践，甚至重复代码。
第 3 步：提高效率和可读性——重构
在这个阶段，我们将通过重写和重构现有代码来展示我们的编程技能，同时确保所有测试保持绿色。
我的观点：
TDD 不是我们需要首先学习的框架/技术堆栈，而是我们可以在团队文化中采用的一种行为。
以下是我在接受 TDD 后的一些重要收获：
- 让事情变绿： 由于我总是在实际实施之前编写详尽的测试用例套件，因此我认为让事情变得绿色是一个挑战 **** 在执行的同时。
- 简单的代码，好的设计： TDD 可帮助您编写最少的代码，而不会出现未来代码，并始终保持精简和干净，因此有时也称为测试驱动设计。
- 很多问题： 写作 **** 测试最初会在用户故事的初始阶段提出很多问题，例如“我们返回的日期应该是什么格式？”、“我们应该考虑在不同的屏幕尺寸上运行应用程序吗？”、“我们应该返回一个数字还是一个字符串？”
- 文件： 在敏捷的工作方式中，需要满足交付时间表，因此编写详尽的测试套件往往会退居二线，采用 TDD 帮助我编写了高质量的测试用例，作为新加入团队的人的功能文档
奖励：TDD 和配对
我们可以利用结对编程和 TDD 的潜力来进一步提高可交付成果的质量。这将确保在全面的测试用例集以及代码和设计质量方面的最佳输出。带有结对编程的 TDD 可以通过多种方式完成：
- 一个编写测试，另一个编写代码以使这些测试通过。
- 两者一起编写详尽的测试，然后编写相应的代码。
- 一个人可以考虑整体设计（测试和代码），其他人可以同时实现它
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
本文链接：https://www.qanswer.top/11896/20380405
标签：代码,TDD,套件,测试用例,测试,编写,驱动 来源： https://www.cnblogs.com/amboke/p/16654183.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。