以下内容为方便复习而整理的相关博文的笔记，如有侵权请马上联系删除
参考文章来源2：https://www.yuque.com/u/gn7vz8/lg8q42
可以帮助我们。
日常开发通常涉及到 业务代码的开发 以及 函数、组件库的开发。
针对这两方面的自动化测试，在模式和流程上也有各自的要求与侧重。
这就衍生出了单元测试和集成测试两种测试方法，以及TDD与BDD的测试开发流程。
概念
可以理解为对系统的某个单元进行测试，而这个，对于这种测试形式来说，我们。。
●
，重点关注各个单元串联起来之后的系统整体功能是否正常。。
以上是两种测试方法，但有时测试的细化程度与系统复杂的操作流程难以平衡，这就需要做出取舍，针对不同的开发主体以及业务场景采用不同的 测试+开发 的流程。
● TDD: 测试驱动开发（Test-Driven Development）
1. 步骤
1. 先编写测试用例，在测试用例的指导下去完善功能，
2. 当测试用例编写完并且都通过测试之后，相应的功能也就做完了。
但通常在代码发生变化的时候，测试用例也要进行相应的调整。
3. 思想：
4. 本质：分离关注点，一次只戴一顶帽子
需求
实现
设计
5. how
6. 案例
火星车
Element3 Button 测试用例
7. TDD 测试模型三部曲
given 准备测试数据
when 触发测试动作
then 验证
8. jest 关键字
• describe 描述, decribe会形成一个作用域
• it 断言
• expect 期望，expect(sum(1, 2)).toBe(3) 的意思是 预计sum(1,2)的值严格等于3。
• test 测试，类似于 it
● BDD: 行为驱动开发（Behavior Driven Development）
测试用例模拟用户的操作行为，通常在完成业务代码开发之后，以用户的操作为指导编写测试代码。
当测试用例跑通之后，就可以认为系统的整体流程已经流畅。
因为业务的需求有可能变更频繁，但操作流程有可能不会变化，当业务代码发生变化的时候，可以使用原来的测试用例继续跑代码，节省了开发时间。
● 注意
TDD需要在测试的指导下写代码，关注点稍微偏重于测试。
使用单元测试结合测试驱动开发的流程，应该逐一梳理功能，。
针对功能点和组件各自的职责，先写测试代码，然后写业务代码，让业务最后通过测试，完成开发。
同时采用单元测试的方式，要保证所编写的测试用例，只针对组件本身的功能。
TDD由于是先写测试用例再进行开发，所以会保证每个功能的代码都是经过测试的，bug自然就少了很多。
同时在编写测试代码的时候，很自然地要去思考这个功能的代码如何组织，也在一定程度上提高了代码的可维护性。
● 问题（单元测试会保证测试覆盖率非常高，但在业务开发的场景下，带来了几个问题）
1. ，demo中为了测试功能编写了很多的测试用例，有时单元测试代码甚至会比业务代码多。
2. ，测试用例中使用了业务中一些模拟的数据，当业务代码变更的时候，要去重新组织测试用例。
3. ，由于单元测试只关注这一个单元的健康状况，无法保证多个单元组成的整体是否正常。
以上问题说明，下面就介绍一种适合业务场景的测试方法。
● 注意
BDD实际上是模拟用户的行为，在业务代码完成后，用测试用例模拟用户的操作行为，，。
由于是先完成业务代码，再做测试。
● 优点
通过上面这个demo可以明白集成测试相对于单元测试，更多，假如一个组件本身没有问题，但与其他组件配合的时候出问题了，那整个流程是不会通过测试的。
。而且只要操作流程不会变，那测试用例也基本不用动，。
自动化测试确实会在一定程度上增加开发的工作量，但经过测试的系统，稳定性的提升会让我们更有信心。
以上两种开发+自动化测试的组合模式（TDD+单元测试 / BDD+集成测试）可以，希望大家可以针对自己的场景，选择合适的方式来引入自动化测试，无论是对提升系统健壮程度还是深化前端工程化，都非常有帮助。
到此这篇TDD测试驱动开发（TDD测试驱动开发步骤）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/kotlinkf/29417.html