摘要：就目前我的面試經(jīng)驗(yàn)而言，絕大部分項(xiàng)目都沒有引入自動化測試，測試基本都是依靠開發(fā)人員的自測以及測試人員黑盒測試。本文不探討黑盒測試，僅僅發(fā)表一點(diǎn)我對自動化測試的想法。緣起早在兩年多以前，就在思考如何做的測試，保證返回的結(jié)果與預(yù)期的一致。

目前，前后端分離的開發(fā)模式越來越受到大家的青睞，前端與后端的職責(zé)也更加清晰，后端通過 API 提供數(shù)據(jù)，前端通過 API 獲取數(shù)據(jù)，展示頁面，前端有更大的發(fā)揮空間、后端也可以更加專注于數(shù)據(jù)處理。

在這樣的時(shí)代大背景下，我嘗試從后端的角度出發(fā)，通過一系列文章，探討后端開發(fā)人員應(yīng)該如何交付高質(zhì)量的 API 接口，減少溝通成本，降低「聯(lián)調(diào)」可能出現(xiàn)的問題，保證代碼質(zhì)量以及項(xiàng)目按期完成。

就目前我的面試經(jīng)驗(yàn)而言，絕大部分項(xiàng)目都沒有引入自動化 API 測試，測試基本都是依靠開發(fā)人員的自測以及測試人員黑盒測試。本文不探討黑盒測試，僅僅發(fā)表一點(diǎn)我對自動化 API 測試的想法。

首先，在我來看，缺少自動化 API 測試可能存在以下問題：

API 實(shí)現(xiàn)與設(shè)計(jì)不符，比如缺少字段或者字段類型不正確

API 無法形成完整閉環(huán)，缺少功能，「聯(lián)調(diào)」還需要不斷修改

新加功能可能導(dǎo)致已有 API 出現(xiàn) BUG，手動回歸測試耗時(shí)且繁瑣

API 測試是一個(gè)比較大的主題，本文主要就「如何讓 API 的實(shí)現(xiàn)與設(shè)計(jì)相符合」這一點(diǎn)出發(fā)，說一說我的想法及開發(fā) Json Validator 的心路歷程。

早在兩年多以前，就在思考如何做 API Schema 的測試，保證 API 返回的結(jié)果與預(yù)期的一致。當(dāng)時(shí)發(fā)現(xiàn)了 Json-Schema 這個(gè)工具，也研究了一番，但上手成本還是略高，最終并沒有實(shí)質(zhì)的產(chǎn)出什么東西。

然后去年在開發(fā) Blink Framework 的 API 測試組件的時(shí)候，發(fā)現(xiàn) Laravel 中 驗(yàn)證 Json 的用法，很簡潔優(yōu)雅，同時(shí) Codeception 也有類似的組件。

于是我就在想，有沒有可能結(jié)合這兩種方式的優(yōu)點(diǎn)，自己開發(fā)一個(gè) Json Validator，保持嚴(yán)謹(jǐn)?shù)耐瑫r(shí)盡可能簡單易用。

正好2017新的一年，公司產(chǎn)品需要對外提供新的 Open API，方便與合作廠商就行業(yè)務(wù)對接。我認(rèn)為這是一個(gè)實(shí)驗(yàn)和推行新 API 測試方式的時(shí)機(jī)，于是便利用假期的時(shí)間，開發(fā)出了 Json Validator 的原型，讀者可以在 rethinkphp/json-validator 查看它的最新代碼。
Json Validator 通過簡單的語法定義 Json 結(jié)構(gòu)，然后驗(yàn)證給定的數(shù)據(jù)是否滿足預(yù)定義的 Json 結(jié)構(gòu)，比 Json-Schema 更加簡單易用。

除了保證設(shè)計(jì)的簡潔優(yōu)雅外，Json Validator 引入類型系統(tǒng)的概念，通過開發(fā)者自定義類型，實(shí)現(xiàn)類型的復(fù)用與自由組合，讓 Json 的驗(yàn)證更方便高效，只要一個(gè)項(xiàng)目的基礎(chǔ)類型定義好了，剩下基本搭積木組裝即可。

Json Validator 默認(rèn)提供7種內(nèi)置類型，他們分別是: integer, double, boolean, string, number, array 和 object。開發(fā)者也可以定義自己的復(fù)合數(shù)據(jù)類型，如下的例子定義了一個(gè) User 復(fù)合類型：

$validator->defineType("User", [
    "name" => "string",
    "gender" => "string",
    "age" => "?integer",
]);

這個(gè) User 類型有三個(gè)屬性，name、gender 和 age，其中 name 和 gender 都是 string 類型，age 為 integer 類型，但允許為 null。這里我們在類型的前面加一個(gè) ? 表示該字段可以為 null。

除了定義復(fù)合數(shù)據(jù)類型，我們也可以定義列表類型，比如定義一個(gè) UserCollection 的類型，它是一個(gè)數(shù)組，數(shù)組的每個(gè)元素都是 User：

$validator->defineType("UserCollection", ["User"]);

要定義一個(gè)列表類型，類型的定義必須是只有一個(gè)元素的數(shù)組，數(shù)組的第一個(gè)元素即該列表類型所允許容納的類型。

對于復(fù)雜應(yīng)用場景，我們也可以使用 PHP 的 callable 來定義更靈活的類型，如下我們定義一個(gè) timestamp 的類型，它驗(yàn)證給定的值必須是合法的時(shí)間字符串。

$validator->defineType("timestamp", function ($value) {
    if ((!is_string($value) && !is_numeric($value)) || strtotime($value) === false) {
        return false;
    }

    $date = date_parse($value);

    return checkdate($date["month"], $date["day"], $date["year"]);
});

定義好了數(shù)據(jù)類型之后，我們就可以驗(yàn)證給定的數(shù)據(jù)是否符合定義，如果不符合定義，Validator 會給出錯(cuò)誤信息。

use rethinkphpjsvValidator;

$validator = new Validator();
// $validator->defineType(...)  Add your custom type if necessary

$matched = $validator->matches($data, "User");
if ($matched) {
    // Validation passed
} else {
    $errors = $validator->getErrors();
}

在一些場景下，我們希望我們定義的類型與給定的數(shù)據(jù)完全匹配，不需要多余的字段，這個(gè)時(shí)候可以使用 Json Validator 的嚴(yán)格模式：

$data = [
    "name" => "Bob",
    "gender" => "Male",
    "age" => 19,
    "phone" => null, // This property is unnecessary
];
$matched = $validator->matches($data, "User", true); // strict mode is turned on
var_dump($matched); // false is returned

這個(gè)例子就會驗(yàn)證失敗，因?yàn)?phone 字段在 User 中并沒有定義。

本文介紹了我開發(fā) Json Validator 的背景和過程以及它的簡單用法，但我也在想它的使用場景可能不僅局限于此，下面是我對其未來的一些想法：

類型系統(tǒng)與文檔生成工具相結(jié)合，從代碼直接生成 API 文檔的數(shù)據(jù)模型部分

自動生成 Json-Schema 定義文件，跨語言使用更方便

通過生成 Json-Schema 定義文件，實(shí)現(xiàn)自描述 RESTFul API

未完待續(xù)...

本文首發(fā)于「代碼寫詩」微信公眾號及同名知乎專欄

掃描二維碼關(guān)注「代碼寫詩」公眾號
微信公眾號: https://mp.weixin.qq.com/s/cN...
知乎專欄: https://zhuanlan.zhihu.com/p/...