前端自动化测试：TDD 和 BDD 哪个好？

2022-08-04 11:53:10玩技站长

玩技站长

管理员, Keymaster

关注

10834
文章

669
评论

测试资讯评论144字数 2617阅读8分43秒阅读模式

摘要不同代码的测试应该相互独立，一个类对应一个测试类(对于 C 代码或 C++ 全局函数，则一个文件对应一个测试文件)，一个函数对应一个测试函数。

TDD 原则

独立测试

不同代码的测试应该相互独立，一个类对应一个测试类(对于 C 代码或 C++ 全局函数，则一个文件对应一个测试文件)，一个函数对应一个测试函数。文章源自玩技e族-https://www.playezu.com/194498.html

用例也应各自独立。每个用例不能使用其他用例的结果数据，结果也不能依赖于用例执行顺序。文章源自玩技e族-https://www.playezu.com/194498.html

一个角色：开发过程包含多种工作，如：编写测试代码、编写产品代码、代码重构等。做不同的工作时，应专注于当前的角色，不要过多考虑其他方面的细节。文章源自玩技e族-https://www.playezu.com/194498.html

测试列表文章源自玩技e族-https://www.playezu.com/194498.html

代码的功能点可能很多，并且需求可能是陆续出现的，任何阶段想添加功能时，应把相关功能点加到测试列表中，然后才能继续手头工作，避免疏漏。文章源自玩技e族-https://www.playezu.com/194498.html

测试驱动文章源自玩技e族-https://www.playezu.com/194498.html

即利用测试来驱动开发，是TDD的核心。要实现某个功能，要编写某个类或某个函数，应首先编写测试代码，明确这个类、这个函数如何使用，如何测试，然后在对其进行设计、编码。文章源自玩技e族-https://www.playezu.com/194498.html

先写断言文章源自玩技e族-https://www.playezu.com/194498.html

编写测试代码时，应该首先编写判断代码功能的断言语句，然后编写必要的辅助语句。文章源自玩技e族-https://www.playezu.com/194498.html

可测试性文章源自玩技e族-https://www.playezu.com/194498.html

产品代码设计、开发时应尽可能提高可测试性。每个代码单元的功能应该比较单纯，“各家自扫门前雪”，每个类、每个函数应该只做它该做的事，不要弄成大杂烩。尤其是增加新功能时，不要为了图一时之便，随便在原有代码中添加功能，对于 C++ 编程，应多考虑使用子类、继承、重载等OO方法。

及时重构

对结构不合理，重复等“味道”不好的代码，在测试通过后，应及时进行重构。

小步前进

软件开发是复杂性非常高的工作，小步前进是降低复杂性的好办法。

TDD 的优点

保证代码质量，因为先编写测试，所以可能出现的问题都被提前发现了;
促进开发人员思考，有利于程序的模块设计;
测试覆盖率高，因为后编写代码，因此测试用例基本都能照顾到;

TDD 的缺点

代码量增多，大多数情况下测试代码是功能代码的两倍甚至更多;
业务耦合度高，测试用例中使用了业务中一些模拟的数据，当业务代码变更的时候，要去重新组织测试用例;
关注点过于独立，由于单元测试只关注这一个单元的健康状况，无法保证多个单元组成的整体是否正常;

个人理解在前端应用实际开发过程中 TDD 更适合开发纯函数库，比如 Lodash、Vue、React 等。

BDD

TDD 最大一个问题是在于开发人员最终做出来的东西和实际功能需求可能相偏离，为了解决这一问题有人发明了 BDD。BDD(Behavior-driven development)行为驱动开发，是测试驱动开发延伸出来的一种敏捷软件开发技术。

BDD 解决的另外一个关键问题就是如何定义 TDD 或单元测试过程中的细节。一些不良的单元测试的一个常见问题是过于依赖被测试功能的实现逻辑。这通常意味着如果你要修改实现逻辑，即使输入输出没有变，通常也需要去更新测试代码。这就造成了一个问题，让开发人员对测试代码的维护感觉乏味和厌烦。

BDD 核心目的是为了解决 TDD 模式下开发和实际功能需求不一致而诞生，BDD 不需要再面向实现细节设计测试，取而代之的是面向行为来测试。它是从产品角度出发，鼓励开发人员和非开发人员(产品、QA、客户等)之间的协作。由于 BDD 的核心是关注软件的功能测试，所以 BDD 更多的是结合集成测试进行，它是黑盒的。