自从我的新书 前端自动化测试框架 – Cypress从入门到精通上市以来,这本书受到了大量同学热情的追捧和讨论。在跟同学们的交流中,我也了解到, 原来除了国外优秀的公司(例如Adobe, 迪士尼,AutoDesk等等), 国内也有很多公司在尝试使用Cypress提升测试效率。而在Cypress中国群内、在公众号iTesting里,我每天都能看到大量关于Cypress的使用讨论和私下问询。这让我感到无比荣幸。(买了书的同学们,公众号回复你的微信,拉你到Cypress中国群)。
除了日常推荐大家通过阅读我的书来解决日常Cypress使用问题外,我也一直在更新着我这边的Cypress知识图谱, 不夸张的说,目前我总结和实践下来知识点多达200多篇。本着“雕琢自我,普惠他人”的原则,我决定在公众号iTesting上开设<你不知道的Cypress系列>专栏。此专栏目的是分享一些我自己趟过的坑,走过的弯路、以及在选型时抛弃了的实践。希望让大家在选用Cypress作为前端自动化测试框架方案时, 可以借鉴一下,避免再走我走过的弯路。
经常有同学问我,为什么不在自动化测试中使用BDD?
进退两难之际,夏侯惇入帐,禀请夜间口号。曹操随口曰:“鸡肋!鸡肋!”
01 什么是BDD?
Behavioural Driven Development (BDD)是从TDD发展来的(什么,TDD你都不知道?!),它通过自然语言定义系统行为,以功能使用者的角度,编写需求场景,且这些行为描述可以直接形成需求文档,同时也是测试标准。
这个概念太绕了,我不准备详细展开。你只要记住,BDD的背后是Gherkin, 而Gherkin的最佳体现是Cucumber框架,所以当你看到有人的测试用例/脚本是下面这个样子时,它就是BDD了。
02 BDD为什么是鸡肋?
本着测试工程师的优良传统 “You Can You Up, No Can No BB”, 我们直接用代码说话:
假设我有一个网站,它如下面这个样子:
它非常简单,当你输入正确的用户名和密码,我就允许你登录。假设我们要测试这个登录功能,那么我们先来看下,该如何测试。
不使用BDD
|
|
可以看到,这个代码非常的Stright Forword。
为了简单起见,在这里我没有用任何的设计模式,实际工作中代码要比这个复杂的多,但是这一点不影响我们的比较,因为即使你用了PO, 用了Custom Commands, 也无非是代码结构更清晰一点,全部放在这里的代码无非分开放到公用Page里,放到Commands.js里。
再来看下,BDD的用法
要使用BDD, 它的文件结构会如下所示:
其中,login.feature文件的代码如下所示:
BDD宣称的最大好处就在这里了:用自然语言描述一个测试,并把它当成测试用例使用。
真的是这样的吗?经验告诉我们,华丽的外袍下面,一定是千疮百孔。来跟我一起解密,这些所谓的”自然语言“是如何起作用的吧。
再来看下Step Definiton, login.js的代码如下:
看到这里,你心里是不是跟我一样,就这??(黑人问号脸), 这难道不是另一种形式的函数吗?或者再高大上一点, 关键字?怎么你就敢这么秀?竟然开宗立派叫自己BDD, 要我说,BDD, 你应该叫“别BB,你就是DD!”
我们再来看运行时表现:
用了BDD后,你的测试用例里只能看到定义的feature文件(华丽的外袍给你看,内里就不好意思拿出来喽~)。
运行一下:
我再次笑了, 除了把我写的描述高亮出来,有什么区别吗??
BDD唯一让我觉得不是一无是处的地方在于,可以给feature文件加标签,支持按标签运行:
然后命令行中运行:
这样能起到一个挑选测试用例运行的目的。
03 总结
我一贯是讨厌BDD的,在初次定义Cypress框架规范时,也有同学建议我用BDD,我都是一票否决的。原因无它,BDD使用下来的唯一感受就是(相信我,我开发基于Python的测试框架时也鄙视过BDD),会写代码的同学不想用BDD,觉得BDD是脱裤子放屁,隔靴搔痒多此一举。不会写代码的同学用不好BDD, 不是说自然语言描述吗?为什么我描述的框架都不认 :)。
BDD除了给我们增加点工作量和Debug负担后,没有带来任何测试效率提升。
正所谓:“进退维谷,曹阿瞒不想吃鸡, 幸灾乐祸,老蔡笑骂BDD”。
(买了书的同学们,公众号回复你的微信,拉你到Cypress中国群)。