基于 BDD 理论的 Nebula 集成测试框架重构（上篇）

测试框架的演进 

截止目前为止，在 Nebula Graph 的开发过程中，测试框架一共发生三次较大的改动，如下图所示。在不断的演进中，团队还是积累了一些经验和教训，希望借由此文做个简单的介绍和梳理。

对于一个数据库产品而言，测试的重要性不言而喻，如何强调都不为过。所以测试框架无论切换到谁，出发点始终只有一个：方便快速地积累测试用例来保障 Nebula Graph 功能的稳定。这里提到的“方便快速”，不是局限于“开发者”这个群体，而是需要面向 Nebula Graph 的所有用户，可能是运维、文档甚至是非技术相关人员。为了实现这点目标，最好是能够让用户进行“无码编程”甚至不需要编程。

纵观大多数的数据库产品，往往是定制一套自己的文本规则，开发者基于这套规则来提交测试，前期我们也有过这方面的尝试，后续考虑到要从头实现定制功能太多，再加上用户又需要学习一套新的规则，最终没有真正地切换过去。直到我们开始做兼容 openCypher 的 MATCH 功能时，注意到 TCK 这个 repo，这虽然是一个兼容性的测试套件，但给我们实现 Nebula Graph 的集成测试提供了新的思路。

前述尝试不好落地的一个原因是 Nebula Graph 返回的结果集中是一个可能含有点、边和路径的复合数据结构，采用类似 JSON 的方式不是不可，只是不够优雅简洁。结果集多了之后，便有“形式”大于“内容”之嫌，结构上的描述远超真正关心的数据，啰嗦冗长，不胜其烦。而 TCK 中制定的这套点、边和路径的描述规则足够简单直观，又契合 MATCH 中的 Pattern 语句，前后呼应，只要用过 openCypher 的用户，很容易接受和理解。只是针对 Nebula Graph 的强 schema 要求，需要对其规则做些拓展，但无伤大雅，鉴于上述的优点，让我们坚定地走向 BDD 的测试框架。

首先通过下述测试用例的复杂度比较，我们可以直观地感受到每一次的进步，从上至下依次为：

1. 基于 GTest 的测试；

2. 基于 pytest 的测试；

3. 基于 BDD 的测试。

[基于 GTest 的测试]

[基于 pytest 的测试]

[基于 BDD 的测试]

从上述对比可以看出，我们越来越靠近“测试”本真，只要关心输入和输出，无需再编码组装测试数据，再辅以一些小的自动化工具，便极大地降低了添加用例的门槛。

期望和实现 

在拓展基于 TCK 的测试框架之前，我们给本次的升级定了如下几个期望达成的目标：

1. 添加用例简单，构造期望数据方便；
2. 支持导入其他的测试数据集；
3. 复用 pytest 框架的灵活性，尤其是 plugins 和 fixture 等机制；
4. 兼容 Match TCK 用例；

为了达成上述目标，我们开始了新的技术选型和模块设计。在构建 Nebula Graph 自己的 TCK 测试框架之前，首选要选择一个“合适的”测试框架，针对该框架的基本要求有如下的几点：

1. 对基于 BDD 的测试有完善的支持；
2. 方便灵活可拓展；
3. 最好能与已有的 pytest 的用例兼容并存。

实现 BDD 的测试框架有很多，即便在 python 语言环境下也是一道多选题，比如 pytest-bdd, behave 等。鉴于上述目标中的第三点，我们选择了基于 pytest-bdd 来构建 Nebula Graph 的整个测试流程。pytest-bdd 是 pytest 的一个插件，在很好的支持 BDD 特性的同时又可以直接利用 pytest 的功能，比较契合我们的预期。

在选定测试框架之后，便开始设计整个测试流程的各个模块，大体结构可以划分为五个部分： 、 DataLoader 、 Parser 、 Comparator 、 Reporter 。

>>>>

ConnectionManager

管理同 Nebula Graph 之间的连接，包括出错重试、错误过滤等功能。

>>>>

DataLoader

读取 CSV 数据文件，解析配置中的数据类型，拼接插入数据的 INSERT 语句等。

>>>>

Parser

解析 TCK 中描述的点、边和路径的字符串，转成 Nebula 定义的 Value 结构，方便比较。

>>>>

Comparator

负责不同的 Value 结构的值比较，包括基础数据类型和复合数据类型，复合数据类型有：List、Map、Set、Vertex、Edge 和 Path 等。

>>>>

Reporter

更好地输出出错的 nGQL 语句在 feature 文件中的位置和行号等定制功能。

模块之间相互独立又相互联系，再配合着 pytest 中 fixture 不同的 scope 可以很好的完成不同场景的隔离和测试。

何为 BDD 

前文提到了很多次的 BDD，我们了解 TDD 和 DDD 比较多，可能对何为 BDD 还持有疑问。所谓 BDD 其实是由 TDD 演进而来的一种测试方法，即行为驱动测试（behavior-driven development）。通过用自然语言书写测试用例的方式完成测试，对开发人员之外的参与者更加的友好，从而拉近了开发者和用户之间的距离。在我们实践过程中发现，其实 BDD 的这套方式方法不止对管理软件质量有效，对繁杂的需求管理也是一个很好的补充手段。用户的需求描述不再局限于复杂的场景描述，可以通过期望的查询语句、过程和结论来跟开发者对齐功能需求，这些需求文件在功能开发完毕之后反过来又变成了测试场景用例，可谓一举两得。

说到 BDD，不得不提 Gherkin 语言。它定义了一组基本的语法规则用来有效的组织普通文本的结构，以便于 BDD 测试工具可以理解文本中描述的内容。存放 Gherkin 语言文本的文件名以 .feature 结尾，其中可以描述很多的场景（Scenario）以及每个场景中的步骤是什么（Given/When/Then）。这些语法的规则简单，关键词也少，所以阅读 Gherkin 的测试文本就像“一问一答”的对话，通俗易懂。

Nebula Graph 的测试框架期望借助 BDD 的方法打造一个纯“黑盒”的测试流程，无论用户是否是开发者都只需要关注两点，输入的 nGQL 是什么和期望返回的结果是什么？如此才能减轻用户添加用例的心智负担，方便其为 Nebula Graph 添砖加瓦。在我们完成框架改造半年之内，内部便已经积累了超过 2,500 个测试用例，1,000 多个测试场景，为 2.0 项目的重构提供了有力的质量保证。所有的用例都分门别类的置于 repo 中的 tests/tck/features 目录中，这些用例本质上也是一部 nGQL 的使用指南，下次用户再碰到棘手的问题不知如何用 nGQL 描述时，也可以先参考这里的用例。

总结 

本篇简单回顾了 Nebula Graph 的测试框架的演变历程和模块设计，后续会向大家展示目前测试框架已经完成的功能以及如何使用它来对 Nebula Graph 源码的改动进行测试。

文章转载自公众号：Nebula Graph Community