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

本文首发于 Nebula Graph 公众号 NebulaGraphCommunity，Follow 看大厂图数据库技术实践。

测试框架的演进

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

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

纵观大多数的数据库产品，每每是定制一套本身的文本规则，开发者基于这套规则来提交测试，前期咱们也有过这方面的尝试，后续考虑到要从头实现定制功能太多，再加上用户又须要学习一套新的规则，最终没有真正的切换过去。直到咱们开始作兼容 openCypher 的 MATCH 功能时，注意到 TCK 这个 repo，这虽然是一个兼容性的测试套件，但给咱们实现 Nebula Graph 的集成测试提供了新的思路。前述尝试很差落地的一个缘由是 Nebula Graph 返回的结果集中是一个可能含有点、边和路径的复合数据结构，采用相似 JSON 的方式不是不可，只是不够优雅简洁。结果集多了以后，便有“形式”大于“内容”之嫌，结构上的描述远超真正关心的数据，啰嗦冗长，不胜其烦。而 TCK 中制定的这套描述点、边和路径的描述规则足够简单直观，又契合 MATCH 中的 Pattern 语句，先后呼应，只要用过 openCypher 的用户，很容易接受和理解。只是针对 Nebula Graph 的强 schema 要求，须要对其规则作些拓展，但无伤大雅，鉴于上述的优势，让咱们坚决的走向 BDD 的测试框架。

Nebula Graph 端到端的功能测试实际上是个“黑盒”测试，主要完成的事情抽象出来就是：执行一条 nGQL 语句，比较返回的结果集。

首先经过下述测试用例的复杂度比较，咱们能够直观的感觉到每一次的进步，从上至下依次为：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 的功能，比较契合咱们的预期。

在选定测试框架以后，便开始设计整个测试流程的各个模块，大致结构能够划分为五个部分：ConnectionManager、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 添砖加瓦。在咱们完成框架改造半年以内，内部便已经积累了大约 2500 个测试用例，为 2.0 项目的重构提供了有力的质量保证。全部的用例都分门别类的置于 repo 中的 tests/tck/features 目录中，这些用例本质上也是一部 nGQL 的使用指南，下次用户再碰到棘手的问题不知如何用 nGQL 描述时，也能够先参考这里的用例。

总结

本篇简单回顾了 Nebula Graph 的测试框架的演变历程，后续会向你们展现目前测试框架已经完成的功能以及如何使用它来测试对 Nebula Graph 源码的改动。

交流图数据库技术？加入 Nebula 交流群请先填写下你的 Nebula 名片，Nebula 小助手会拉你进群~~