根据 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 助手会拉你入群~~