> 本文首發於 Nebula Graph 公眾號 [NebulaGraphCommunity](https://www-cdn.nebula-graph.com.cn/nebula-blog/WeChatOffical.png)，Follow 看大廠圖資料庫技術實踐。

![基於 BDD 理論的 Nebula 整合測試框架重構（下篇）](https://www-cdn.nebula-graph.com.cn/nebula-blog/bdd.png)

在[上篇文章](https://mp.weixin.qq.com/s/gw1hJetflofQc2aiiZ6frA)中，我們介紹了 Nebula Graph 的整合測試的演進過程。本篇就介紹一下向測試集合中新增一個用例，併成功執行所有的測試用例的過程。

## 環境準備

在構建 2.0 測試框架之初，我們定製了部分工具類來幫助測試框架快速地啟停一個單節點的 nebula 服務，其中有檢查埠衝突、修改部分配置選項等功能。原來的執行流程如下:

1. 透過 python 指令碼啟動 nebula 的服務；
2. 呼叫`pytest.main`併發執行所有的測試用例；
3. 停止 nebula 的服務。

其中的不便之處在於，當需要給 pytest 指定某些引數選項時，需要將該引數透傳給`pytest.main`函式，並且每次執行單個測試用例需要透過`cmake`生成的指令碼來操作，不是很方便。我們希望“測試用例在哪兒，就在哪兒執行測試”。

### 服務啟動

在本次測試框架的改造過程中，我們除了改變了程式入口之外，大部分複用了原來封裝好的邏輯。由於 nebula 目前積累了很多的用例，單程式執行已經不能滿足快速迭代的需求，在嘗試了其他並行外掛之後，考慮到相容性，我們最終選擇了 pytest-xdist 外掛來加速整個測試流程。

但是 pytest 只提供了四種 scope 的 fixture：session，module，class 和 function。而我們希望能用一種 global 級別的 fixture 來完成 nebula 服務的啟動和初始化。目前最高層次的 session 級別還是每個 runner 都要執行一次，如此如果有 8 個 runner 的話，就要啟動 8 個 nebula 服務，這不是我們期望的。

參考 pytest-xdist 的[文件](https://github.com/pytest-dev/pytest-xdist#making-session-scoped-fixtures-execute-only-once)，需要透過檔案鎖來進行不同 runner 之間的並行控制。為了讓控制邏輯足夠的簡單，我們把程式啟停和預備的邏輯同執行測試的過程分開，使用單獨的步驟控制 nebula 的啟動，當某些測試有問題時，還可以透過 nebula-console 單獨連線測試的服務，進行進一步的驗證除錯。

### 資料匯入

在此之前，Nebula 的資料匯入過程是直接執行一條拼接好的 nGQL INSERT 語句。這樣做，存在如下問題：

1. 測試資料集大的情況，INSERT 語句會變得冗長，client 執行超時；
2. 不易擴充新的測試資料集，需要將現成的 csv 資料檔案構造成對應的 nGQL 語句檔案；
3. 不能複用相同的資料集，比如希望同一份 csv 匯入到不同 VID 型別的 space 中測試，需要構造不同的 INSERT 語句。

針對以上的問題，參考[nebula-importer](https://github.com/vesoft-inc/nebula-importer)的實現，我們將匯入的邏輯和資料集完全分離，重新實現了 python 版的匯入模組。不過，目前只支援匯入 csv 型別的資料檔案，且每個 csv 檔案中只能儲存一個`tag/edge`型別。

重構匯入的邏輯之後，目前 nebula 的測試資料集變得清晰明瞭：

```tree
nebula-graph/tests/data
├── basketballplayer
│   ├── bachelor.csv
│   ├── config.yaml
│   ├── like.csv
│   ├── player.csv
│   ├── serve.csv
│   ├── team.csv
│   └── teammate.csv
├── basketballplayer_int_vid
│   └── config.yaml
└── student
    ├── config.yaml
    ├── is_colleagues.csv
    ├── is_friend.csv
    ├── is_schoolmate.csv
    ├── is_teacher.csv
    ├── person.csv
    ├── student.csv
    └── teacher.csv
 
3 directories, 16 files
```

每個目錄包含一個 space 中所有的 csv 資料檔案，透過該目錄下的`config.yaml`來配置每個檔案的描述以及 space 的詳細資訊。透過這份配置資訊，我們也實現了 basketballplayer 和 basketballplayer`_int_vid`兩個 space 共享同一份資料。以後如果想新增新的測試資料集，只要增加一個類似 basketballplayer 的資料目錄即可。`config.yaml`的具體內容見[repo](https://github.com/vesoft-inc/nebula-graph/blob/master/tests/data/nba/config.yaml)。

### 安裝依賴

除卻常用的 pytest 和 nebula-python 庫之外，目前的測試框架還用到了 pytest-bdd 和 pytest-xdist 等外掛。此外，為了更好地統一新增測試用例 feature 檔案的格式，我們引入了社群的[reformat-gherkin](https://github.com/ducminh-phan/reformat-gherkin)工具，並基於此做了[部分格式的調整](https://github.com/OneContainer/reformat-gherkin)，來保持與 openCypher TCK feature 檔案的格式統一。

目前 nebula-python 和 reformat-gherkin 兩款外掛都是透過原始碼直接安裝，我們在`nebula-graph/tests`下提供了`Makefile`來簡化使用者的操作流程。執行測試的所有環境準備只需要執行命令：

```plain
$ cd nebula-graph/tests && make init-all
```
我們也將上述格式檢查整合到了 GitHub Action 的 CI 流程中，如果使用者修改的測試檔案格式不合預期，可透過`make fmt`命令做本地的格式化處理。
## 編寫用例

由上篇所述，現在 nebula 的整合測試變為“黑盒”測試，使用者不再需要關心自己編寫的語句怎麼呼叫，呼叫什麼函式比較符合預期結果。只要按照約定的規範，使用近似“自然語言”的方式在 feature 檔案中描述自己的用例即可。以下是一個測試用例的示例：

```
Feature: Variable length pattern match (m to n)
  Scenario: both direction expand with properties
    Given a graph with space named "basketballplayer"
    When executing query:
      """
      MATCH (:player{name:"Tim Duncan"})-[e:like*2..3{likeness: 90}]-(v)
      RETURN e, v
      """
    Then the result should be, in any order, with relax comparison:
      | e                                                                                  | v                  |
      | [[:like "Tim Duncan"(:L2)>`。

但是 Nebula Graph 同 Neo4J 的在圖模型上還是有一些不同，比如在 Nebula Graph 中每個 Tag 均可以有自己的屬性，那麼按照現有的表述方式是不能描述含有多個帶屬性 Tag 的 vertex 的。在邊的表示上也有差異，Nebula Graph 的 Edge Key 是由四元組組成`<src type="" rank="" dst="">`，而現有的表示也不能描述邊的 src、dst 和 rank 的值。故而在考慮了這些差異之後，我們擴充了現有 TCK 的 expected results 表達：

1. 點的描述支援帶屬性的多個 Tag：`("VID" :T1{p:0} :T2{q: "string"})`；
2. 邊的描述支援 src、dst 和 rank 的表示：`[:type "src"->"dst"@rank {p:0, q:"string"}]`；
3. 路徑就是迴圈上述點邊的表示即可，同 TCK 。

透過上述的點邊描述方式上的擴充，即相容 TCK 現有用例，又契合了 Nebula Graph 的設計。在解決了表達方式上的問題後，面臨的下一個問題是如何高效無誤地轉化上述的表示到具體的資料結構，以便能夠跟真正的查詢結果做比較。在考慮了正則匹配、parser 解析等方案後，我們選擇構造一個解析器的方式來處理這些具有特定語法規則的字串，這樣做的好處有如下的幾點：

1. 可以根據具體的語法規則讓解析出來的 AST 符合查詢返回結果的資料結構，兩者再進行比較時，便是具體結構中的具體欄位的校驗了；
2. 避免處理複雜的正則匹配字串，減少解析的錯誤；
3. 可以支援其他字串解析的需求，比如正規表示式、列表、集合等

藉助ply.yacc 和 ply.lex 兩個 library，我們可以用少量的程式碼實現上述複雜的需求，具體實現見[nbv.py 檔案](https://github.com/vesoft-inc/nebula-graph/blob/master/tests/tck/utils/nbv.py)。

## 測試流程

目前的測試流程變為：

#### 1) 編寫 Feature 檔案

目前 Nebula Graph 所有的 feature 用例均位於 github.com/vesoft-inc/nebula-graph repo 中的[tests/tck/features](https://github.com/vesoft-inc/nebula-graph/tree/master/tests/tck/features)目錄中。

#### 2) 啟動 nebula graph 服務

```
$ cd /path/to/nebula-graph/tests
$ make up # 啟動 nebula graph 服務
```

#### 3) 本地執行測試

```
$ make fmt # 格式化
$ make tck # 執行 TCK 測試
```

#### 4)停止 nebula graph 服務

```
$ mak
e down
```
### 除錯

當編寫的用例需要除錯時，便可以使用 pytest 支援的方式來進一步的除錯，比如重新執行上次過程中失敗的用例：

```
$ pytest --last-failed tck/ # 執行 tck 目錄中上次執行失敗的用例
$ pytest -k "match" tck/    # 執行含有 match 欄位的用例
```

也可以在 feature 檔案中對特定的一個 scenario 打上一個 mark，只執行該被 mark 的用例，比如：

```
# in feature file
  @testmark
  Scenario: both direction expand with properties
    Given a graph with space named "basketballplayer"
    ...
 
# in nebula-graph/tests directory
$ pytest -m "testmark" tck/ # 執行帶有 testmark 標記的測試用例
```

## 總結

站在前人的肩膀之上才讓我們找到更適合 Nebula Graph 的測試方案，在此也一併感謝文中提到的所有開源工具和專案。

在實踐 pytest-bdd 的過程中，也發現其中一些不完美的地方，比如其跟 pytest-xdist 等外掛相容性的問題(gherkin-reporter)，還有 pytest 沒有原生提供 global scope 級別的 fixture 等。但終究其帶給 Nebula Graph 的收益要遠大於這些困難。

上篇中有提到不需要使用者進行程式設計，並非憑空想象，當我們把上述的模式固定後，可以開發一套新增測試用例的腳手架，讓使用者在頁面上進行資料“填空”，自動生成對應的 feature 測試檔案，如此便可進一步地方便使用者，此處可以留給感興趣的社群使用者來做些嘗試了。

交流圖資料庫技術？加入 Nebula 交流群請先[填寫下你的 Nebula 名片](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手會拉你進群~~

想要和其他大廠交流圖資料庫技術嗎？NUC 2021 大會等你來交流：[NUC 2021 報名傳送門](https://nebula-graph.com.cn/nuc2021/?utm_source=article)</src>

基於 BDD 理論的 Nebula 整合測試框架重構（下篇）

相關文章