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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$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ù)類型之后，我們就可以驗證給定的數(shù)據(jù)是否符合定義，如果不符合定義，Validator 會給出錯誤信息。

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ù)完全匹配，不需要多余的字段，這個時候可以使用 Json Validator 的嚴格模式：

$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

這個例子就會驗證失敗，因為 phone 字段在 User 中并沒有定義。

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

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

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

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

未完待續(xù)...

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

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