BDD行为驱动开发用例实践

关于 TDD 和 BDD 的区别，参考 利用 Behavior Driven Development 技术加强软件自动化测试，简单来说：

TDD：

每写一段代码之前，先写一个单元测试；在单元测试可以运行并失败后，编写代码；待到代码可以使之前的测试通过后，编码完成；在保持测试通过情况下，重构代码。

BDD：

这种开发模式也可以看作是对 TDD 的一种补充，它鼓励软件项目中的开发人员，测试人员和非技术人员或者客户之间的协作，从用户的需求出发，强调系统行为。在 TDD 中，我们并不能完全保证根据设计所编写的测试就是用户所期望的功能，用户并一定能看懂测试用例。BDD 将这一部分用更接近自然语言的形式来描述，让测试用例更自然化和简单，使开发人员，测试人员和客户能在这个基础上达成一致。

本次在有车以后APP的自动化用例适配上，尝试了BDD风格的 behave 框架，感觉非常好，使用情况如下：

1. 代码非常简练

得益于框架对 step、scenario、feature、tag、all 前后回调的钩子，以及自动传递的上下文context环境，使得

• 只需定义少量关键字实现，大大减少了重复代码
• 灵活的实现更强大的功能，例如每一个 step 后自动截图

虽然之前用 pytest 时一直在刻意的抽象、重构代码，比起 behave 这种生来友好的机制还是太多冗余！

@when("左滑")
def step_impl(context):
    width, height = context.driver.get_window_size()['width'], context.driver.get_window_size()['height']
    context.driver.swipe(width * 0.75, height * 0.5, width * 0.25, height * 0.5, duration=800)
    sleep(1)
@then("返回")
def step_impl(context):
    context.driver.back()
    sleep(2)

2. 用例编写速度很快

由于操作被抽象成了少量的几个中文关键字，加上IDE的自动补全，几乎不需要代码层面的思考。

以前写用例像是在写作文，现在则变成了填空题！

3. 用例易读，编写门槛低

通过前后的对比，我发现即使 python 语言再易读，比起 BDD 的中文用例还是差多了，易读易写，这一点非常棒：

  Scenario: 资讯-工具栏-实测排行详情
    Given 进入有车以后主界面
    When 点击实测
    When 随机点前3个实测排行列表
    Then 返回
    When 点击查看更多
    When 随机点前3个车封面图列表
    When 翻1页
    When 左滑

4. 其他特性

• 可以给每一个 step 定义表格数据或者文本数据

  Scenario: Demo
    Given 表格数据
      # context.table
      | name | birth |
      | Alice | 1985 |
      | Bob | 1975 |
      | Charly | 1995 |
    When 文本数据
      # context.text
      """
      这里可以自定义一堆文本
      """

• Scenario Outlines
  编写基于数据模板的测试用例

• Tags、Fixtures
  这些用的还不多

小结：从这短短的几周学习和实践，对BDD这套用例模型有了相见恨晚的感觉，后面会扩大其应用范围，做更多特性探索。