再舉一個例子，假設您正在構建一個允許用戶對投票進行投票的 Web 應用。只能在 AppModelsPoll 模型上指定的 opens_at 時間和 closes_at 時間之間對投票進行投票。如果有人設置投票時不小心將 closes_at 時間設置為早于 opens_at 時間，會發(fā)生什么情況？根據(jù)您在應用中如何處理這種情況，這可能會導致各種問題。

通過在將數(shù)據(jù)存儲到模型之前對其進行驗證，我們可以提高應用中的數(shù)據(jù)準確性，并減少存儲不正確數(shù)據(jù)的可能性。

# 確保 Artisan 命令輸入正確

除了能夠驗證 HTTP 請求中傳遞的數(shù)據(jù)外，您還可以驗證 Artisan 命令。這可以防止開發(fā)人員意外輸入無效值并導致應用出現(xiàn)問題。

客戶端驗證與服務器端驗證

通常，您可以在應用中使用兩種類型的驗證：客戶端驗證和服務器端驗證。

# 客戶端驗證

客戶端驗證是在將數(shù)據(jù)發(fā)送到服務器之前在瀏覽器中執(zhí)行的驗證。它可以使用 JavaScript 甚至 HTML 屬性來實現(xiàn)。

例如，我們可以向 HTML 中的數(shù)字字段添加一些簡單的驗證，以確保用戶輸入的數(shù)字介于 1 和 10 之間：

<input type="number" min="1" max="10" required>

此輸入字段有四個單獨的部分，對客戶端驗證很有用：

type="number"：這告訴瀏覽器輸入應為數(shù)字。在大多數(shù)瀏覽器上，這將阻止用戶輸入數(shù)字以外的任何內容。在移動設備上，它甚至可能會調出數(shù)字鍵盤而不是常規(guī)鍵盤，這對用戶體驗非常有益。
min="1"：這告訴瀏覽器輸入的數(shù)字必須至少為 1。
max="10"：這告訴瀏覽器輸入的數(shù)字最多必須為 10。
required：這告訴瀏覽器該字段是必需的，并且必須在提交表單之前填寫。

在大多數(shù)瀏覽器中，如果用戶嘗試使用無效值（或根本沒有值）提交表單，瀏覽器將阻止提交表單，并向用戶顯示錯誤消息或提示。

這對指導用戶和改善應用的整體用戶體驗非常有益。但這只是它應該被視為：一個指南。您不應僅依賴客戶端驗證作為應用中唯一的驗證形式。

如果有人在瀏覽器中打開開發(fā)者工具，他們可以輕松刪除和繞過您已設置的客戶端驗證。

此外，重要的是要記住，當惡意用戶試圖攻擊您的應用時，他們通常會使用自動化腳本將請求直接發(fā)送到您的服務器。這意味著您已設置的客戶端驗證將被繞過。

# 服務器端驗證

服務器端驗證是在服務器上的應用后端中運行的驗證。在 Laravel 應用的上下文中，這通常是在控制器或表單請求類中運行的驗證。

由于驗證位于您的服務器上，用戶無法更改，因此這是真正確保發(fā)送到服務器的數(shù)據(jù)有效的唯一方法。

因此，務必在您的應用中始終啟用服務器端驗證。理想情況下，您嘗試從請求中讀取的每個字段都應在嘗試使用它執(zhí)行任何業(yè)務邏輯之前進行驗證。

Laravel 如何處理驗證

現(xiàn)在我們已經(jīng)了解了什么是驗證以及它為什么重要，讓我們來看看如何在 Laravel 中使用它。

如果您已經(jīng)使用 Laravel 一段時間了，您就會知道 Laravel 具有內置于框架中的驚人的驗證系統(tǒng)。因此，在您的應用中開始使用驗證非常容易。

在 Laravel 中驗證數(shù)據(jù)有幾種常見方法，但我們將介紹兩種最常見的方法：

手動驗證數(shù)據(jù)
使用表單請求類驗證數(shù)據(jù)

# 手動驗證數(shù)據(jù)

要手動驗證數(shù)據(jù)（例如在控制器方法中），您可以使用 IlluminateSupportFacadesValidator facade 并調用 make 方法。

然后，我們可以將兩個參數(shù)傳遞給 make 方法：

data - 我們要驗證的數(shù)據(jù)
rules - 我們要根據(jù)其驗證數(shù)據(jù)的規(guī)則

旁注：make 方法還接受兩個可選參數(shù)：messages 和 attributes。這些可用于自定義返回給用戶的錯誤消息，但我們不會在本篇文章中介紹它們。

讓我們來看一個您可能想要驗證兩個字段的示例：

<input type="number" min="1" max="10" required>

在上面的示例中，我們可以看到我們正在驗證兩個字段：title 和 body。我們已對這兩個字段的值進行硬編碼以使示例更清晰，但在實際項目中，您通常會從請求中獲取這些字段。我們正在檢查 title 字段是否已設置、是字符串以及最大長度為 100 個字符。我們還檢查 description 字段是否已設置、是字符串以及最大長度為 250 個字符。

創(chuàng)建驗證器后，我們可以調用返回的 IlluminateValidationValidator 實例上的方法。例如，要檢查驗證是否失敗，我們可以調用 fails 方法：

use Illuminate\Support\Facades\Validator;

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

同樣，我們也可以在驗證器實例上調用 validate 方法：

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

if ($validator->fails()) {
    // 一個或多個字段驗證失敗。
    // 在此處進行處理...
}

如果驗證失敗，此 validate 方法將引發(fā) IlluminateValidationValidationException。Laravel 將根據(jù)所進行的請求類型自動處理此異常（假設您沒有更改應用中的默認異常處理）。如果請求是 Web 請求，Laravel 將使用會話中的錯誤將用戶重定向回上一頁以供您顯示。如果請求是 API 請求，Laravel 將返回 422 Unprocessable Entity 響應，其中包含驗證錯誤的 JSON 表示形式，如下所示：

Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
)->validate();

# 使用表單請求類驗證數(shù)據(jù)

在 Laravel 應用中驗證數(shù)據(jù)的另一種常用方法是使用表單請求類。表單請求類是擴展 IlluminateFoundationHttpFormRequest 的類，用于對傳入請求運行授權檢查和驗證。

我發(fā)現(xiàn)它們是保持控制器方法整潔的好方法，因為 Laravel 會在運行控制器方法的代碼之前自動對請求中傳遞的數(shù)據(jù)運行驗證。因此，我們不需要自己記住在驗證器實例上運行任何方法。

讓我們來看一個簡單的例子。假設我們有一個基本的 AppHttpControllersUserController 控制器，其中有一個 store 方法允許我們創(chuàng)建一個新用戶：

<input type="number" min="1" max="10" required>

在控制器方法中，我們可以看到我們接受 AppHttpRequestsUsersStoreUserRequest 表單請求類（我們將在后面介紹）作為方法參數(shù)。這將向 Laravel 指示我們希望在通過 HTTP 請求調用此方法時自動運行此請求類中的驗證。

然后，我們在控制器方法中使用請求實例上的 validated 方法從請求中獲取已驗證的數(shù)據(jù)。這意味著它只會返回已驗證的數(shù)據(jù)。例如，如果我們嘗試在控制器中保存新的 profile_picture 字段，則也必須將其添加到表單請求類中。否則，validated 方法將不會返回它，因此 $request->validated('profile_picture') 將返回 null。

現(xiàn)在讓我們來看看 AppHttpRequestsUsersStoreUserRequest 表單請求類：

use Illuminate\Support\Facades\Validator;

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

我們可以看到請求類包含兩個方法：

authorize：此方法用于確定用戶是否有權發(fā)出請求。如果該方法返回 false，則會向用戶返回 403 Forbidden 響應。如果該方法返回 true，則將運行驗證規(guī)則。
rules：此方法用于定義應在請求上運行的驗證規(guī)則。該方法應返回一個應在請求上運行的規(guī)則數(shù)組。

在 rules 方法中，我們指定 name 字段必須設置、必須是字符串并且最大長度必須為 100 個字符。我們還指定 email 字段必須設置、必須是電子郵件并且在 users 表（在 email 列上）中必須唯一。最后，我們指定 password 字段必須設置并且必須通過我們已設置的默認密碼驗證規(guī)則（我們稍后將介紹密碼驗證）。

如您所見，這是將驗證邏輯與控制器邏輯分離的好方法，我發(fā)現(xiàn)它使代碼更易于閱讀和維護。

Laravel 中常用的驗證規(guī)則

正如我已經(jīng)提到的，Laravel 驗證系統(tǒng)非常強大，可以輕松地將驗證添加到您的應用中。

在本節(jié)中，我們將快速介紹一些我喜歡的便捷驗證規(guī)則，我認為大多數(shù)用戶都會發(fā)現(xiàn)它們在他們的應用中很有用。

如果您有興趣查看 Laravel 中可用的所有規(guī)則，可以在 Laravel 文檔中找到它們：http://miracleart.cn/link/45d5c43856059a4f97d43d6534be52d0

# 驗證數(shù)組

您需要運行的一種常見驗證類型是驗證數(shù)組。這可以是從驗證傳遞的 ID 數(shù)組是否全部有效，到驗證請求中傳遞的對象數(shù)組是否全部具有某些字段。

讓我們來看一個如何驗證數(shù)組的示例，然后我們將討論正在執(zhí)行的操作：

<input type="number" min="1" max="10" required>

在上面的示例中，我們傳遞的是一個對象數(shù)組，每個對象都有一個 name 和 email 字段。

對于驗證，我們首先定義 users 字段已設置并且是數(shù)組。然后，我們指定數(shù)組的每個項目（使用 users.* 定向）都是一個包含 name 和 email 字段的數(shù)組。

然后，我們指定 name 字段（使用 users.*.name 定向）必須設置、必須是字符串并且不能超過 100 個字符。我們還指定 email 字段（使用 users.*.email 定向）必須設置、必須是電子郵件并且在 users 表的 email 列上必須唯一。

通過能夠在驗證規(guī)則中使用 * 通配符，我們可以輕松驗證應用中的數(shù)據(jù)數(shù)組。

# 驗證日期

Laravel 提供了一些您可以使用的便捷日期驗證規(guī)則。首先，要驗證某個字段是否為有效日期，您可以使用 date 規(guī)則：

use Illuminate\Support\Facades\Validator;

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

如果您更喜歡檢查日期是否采用特定格式，您可以使用 date_format 規(guī)則：

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

if ($validator->fails()) {
    // 一個或多個字段驗證失敗。
    // 在此處進行處理...
}

您可能需要檢查日期是否早于或晚于另一個日期。例如，假設您的請求中包含 opens_at 和 closes_at 字段，并且您要確保 closes_at 晚于 opens_at 并且 opens_at 晚于或等于今天。您可以像這樣使用 after 規(guī)則：

Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
)->validate();

在上面的示例中，我們可以看到我們已將 today 作為參數(shù)傳遞給 opens_at 字段的 after 規(guī)則。Laravel 將嘗試使用 strtotime 函數(shù)將此字符串轉換為有效的 DateTime 對象并將其與該對象進行比較。

對于 closes_at 字段，我們將 opens_at 作為參數(shù)傳遞給 after_or_equal 規(guī)則。Laravel 將自動檢測這是另一個正在驗證的字段，并將這兩個字段相互比較。

同樣，Laravel 還提供 before 和 before_or_equal 規(guī)則，您可以使用它們來檢查日期是否早于另一個日期：

{
  "message": "The title field is required. (and 1 more error)",
  "errors": {
    "title": [
      "The title field is required."
    ],
    "description": [
      "The description field is required."
    ]
  }
}

# 驗證密碼

作為 Web 開發(fā)人員，我們的工作是盡力幫助用戶在線安全。我們可以做到這一點的一種方法是在我們的應用中推廣良好的密碼實踐，例如要求密碼具有一定的長度、包含某些字符等。

Laravel 通過提供一個 IlluminateValidationRulesPassword 類來簡化我們的工作，我們可以使用該類來驗證密碼。

它帶有一些我們可以鏈接在一起的方法，以構建我們想要的密碼驗證規(guī)則。例如，假設我們希望用戶的密碼符合以下條件：

至少 8 個字符長
至少包含一個字母
至少包含一個大寫字母和一個小寫字母
至少包含一個數(shù)字
至少包含一個符號
不是被泄露的密碼（即不在包含其他系統(tǒng)數(shù)據(jù)泄露中泄露密碼記錄的 Have I Been Pwned 數(shù)據(jù)庫中）

我們的驗證可能如下所示：

<input type="number" min="1" max="10" required>

如示例所示，我們正在使用可鏈接的方法來構建我們想要的密碼驗證規(guī)則。但是，如果我們在多個不同的地方使用這些規(guī)則（例如注冊、重置密碼、在您的帳戶頁面上更新密碼等），并且我們需要更改此驗證以強制執(zhí)行至少 12 個字符，會發(fā)生什么情況？我們需要遍歷使用這些規(guī)則的所有地方并更新它們。

為了簡化此操作，Laravel 允許我們定義一組默認的密碼驗證規(guī)則，我們可以在整個應用中使用它們。我們可以通過在我們的 AppProvidersAppServiceProvider 的 boot 方法中像這樣使用 Password::defaults() 方法定義一組默認規(guī)則：

use Illuminate\Support\Facades\Validator;

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

執(zhí)行此操作后，我們現(xiàn)在可以在驗證規(guī)則中調用 Password::defaults()，并將我們在 AppServiceProvider 中指定的規(guī)則用于：

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

if ($validator->fails()) {
    // 一個或多個字段驗證失敗。
    // 在此處進行處理...
}

# 驗證顏色

我參與過的幾乎每個項目都包含某種形式的顏色選擇器。無論是用戶為其個人資料選擇顏色、頁面一部分的背景顏色還是其他內容，它都是經(jīng)常出現(xiàn)的內容。

過去，我不得不使用正則表達式（我承認我不太了解）來驗證顏色是否為十六進制格式的有效顏色（例如 #FF00FF）。但是，Laravel 現(xiàn)在有一個方便的 hex_color 可以使用：

Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
)->validate();

# 驗證文件

如果您通過服務器將文件上傳到應用，則需要在嘗試存儲文件之前驗證文件是否有效。正如您所想象的那樣，Laravel 提供了一些您可以使用的文件驗證規(guī)則。

假設您想允許用戶上傳 PDF（.pdf）或 Microsoft Word（.docx）文件。驗證可能如下所示：

{
  "message": "The title field is required. (and 1 more error)",
  "errors": {
    "title": [
      "The title field is required."
    ],
    "description": [
      "The description field is required."
    ]
  }
}

在代碼示例中，我們可以看到我們正在驗證文件類型，還設置了一些最小和最大文件大小限制。我們使用 types 方法來指定我們想要允許的文件類型。

min 和 max 方法還可以接受包含其他后綴的字符串，這些后綴指示文件大小單位。例如，我們還可以使用：

10kb
10mb
10gb
10tb

此外，我們還可以使用 IlluminateValidationRulesFile 類上的 image 方法來確保文件是圖像：

<input type="number" min="1" max="10" required>

在上面的示例中，我們正在驗證文件是否為圖像，設置一些最小和最大文件大小限制，還設置一些最大尺寸（500 x 500 像素）。

您可能希望對應用中的文件上傳采取不同的方法。例如，您可能希望直接從用戶的瀏覽器上傳到云存儲（例如 S3）。如果您更喜歡這樣做，您可能需要查看我的《使用 FilePond 在 Laravel 中上傳文件》文章，該文章向您展示了如何執(zhí)行此操作、您可能需要采取的不同驗證方法以及如何對其進行測試。

# 驗證數(shù)據(jù)庫中是否存在字段

您可能要進行的另一個常見檢查是確保數(shù)據(jù)庫中存在某個值。

例如，假設您的應用中有一些用戶，并且您已創(chuàng)建了一個路由，以便您可以將它們批量分配給團隊。因此，在您的請求中，您可能需要驗證請求中傳遞的 user_ids 是否全部存在于 users 表中。

為此，您可以使用 exists 規(guī)則并傳遞您想要檢查值是否存在其中的表名：

use Illuminate\Support\Facades\Validator;

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

在上面的示例中，我們正在檢查 user_ids 數(shù)組中傳遞的每個 ID 是否都存在于 users 表的 id 列中。

這是確保您正在使用的數(shù)據(jù)有效并且在嘗試使用它之前存在于數(shù)據(jù)庫中的一種好方法。

如果您想更進一步，可以將 where 子句應用于 exists 規(guī)則以進一步過濾運行的查詢：

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

if ($validator->fails()) {
    // 一個或多個字段驗證失敗。
    // 在此處進行處理...
}

在上面的示例中，我們正在檢查 user_ids 數(shù)組中傳遞的每個 ID 是否都存在于 users 表的 id 列中，并且用戶的 is_verified 列設置為 true。因此，如果我們傳遞未經(jīng)驗證的用戶 ID，則驗證將失敗。

# 驗證數(shù)據(jù)庫中字段的唯一性

與 exists 規(guī)則類似，Laravel 還提供了一個 unique 規(guī)則，您可以使用它來檢查數(shù)據(jù)庫中的值是否唯一。

例如，假設您有一個 users 表，并且您要確保 email 字段唯一。您可以像這樣使用 unique 規(guī)則：

Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
)->validate();

在上面的示例中，我們正在檢查 email 字段是否已設置、是電子郵件并且在 users 表的 email 列上是唯一的。

但是，如果我們嘗試在用戶可以更新其電子郵件地址的個人資料頁面上使用此驗證，會發(fā)生什么情況？驗證將失敗，因為 users 表中存在一行包含用戶嘗試更新到的電子郵件地址。在這種情況下，我們可以使用 ignore 方法在檢查唯一性時忽略用戶 ID：

{
  "message": "The title field is required. (and 1 more error)",
  "errors": {
    "title": [
      "The title field is required."
    ],
    "description": [
      "The description field is required."
    ]
  }
}

如果您確實選擇使用 ignore 方法，則應確保閱讀 Laravel 文檔中的此警告：

"您永遠不應將任何用戶控制的請求輸入傳遞到 ignore 方法中。相反，您只應傳遞系統(tǒng)生成的唯一 ID，例如來自 Eloquent 模型實例的自增 ID 或 UUID。否則，您的應用將容易受到 SQL 注入攻擊。"

也可能有時您想向 unique 規(guī)則添加其他 where 子句。您可能需要這樣做以確保電子郵件地址對于特定團隊是唯一的（這意味著不同團隊中的另一個用戶可以使用相同的電子郵件）。您可以通過將閉包傳遞給 where 方法來做到這一點：

<input type="number" min="1" max="10" required>

創(chuàng)建您自己的驗證規(guī)則

盡管 Laravel 附帶了大量內置驗證規(guī)則，但您可能需要創(chuàng)建自定義驗證規(guī)則以適應特定用例。

謝天謝地，這在 Laravel 中也很容易做到！

讓我們來看看如何構建自定義驗證規(guī)則、如何使用它，然后如何為它編寫測試。

出于本文的目的，我們不太關心我們正在驗證的內容。我們只想了解創(chuàng)建自定義驗證規(guī)則的一般結構以及如何對其進行測試。因此，我們將創(chuàng)建一個簡單的規(guī)則來檢查字符串是否為回文。

如果您不知道，回文是一個單詞、短語、數(shù)字或其他字符序列，其正向和反向讀取相同。例如，“racecar”是一個回文，因為如果您反轉字符串，它仍然是“racecar”。而“l(fā)aravel”不是回文，因為如果您反轉字符串，它將是“l(fā)evaral”。

要開始，我們將首先通過在項目路由中運行以下命令來創(chuàng)建一個新的驗證規(guī)則：

use Illuminate\Support\Facades\Validator;

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

這應該為我們創(chuàng)建了一個新的 App/Rules/Palindrome.php 文件：

$validator = Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
);

if ($validator->fails()) {
    // 一個或多個字段驗證失敗。
    // 在此處進行處理...
}

當運行規(guī)則時，Laravel 將自動調用 validate 方法。該方法接受三個參數(shù)：

$attribute：正在驗證的屬性的名稱。
$value：正在驗證的屬性的值。
$fail：如果驗證失敗，您可以調用的閉包。

因此，我們可以在 validate 方法中添加我們的驗證邏輯，如下所示：

Validator::make(
    data: [
        'title' => 'Blog Post',
        'description' => 'Blog post description',
    ],
    rules: [
        'title' => ['required', 'string', 'max:100'],
        'description' => ['required', 'string', 'max:250'],
    ]
)->validate();

在上面的規(guī)則中，我們只是檢查傳遞給規(guī)則的值是否與其反轉的值相同。如果不是，我們將使用錯誤消息調用 $fail 閉包。這將導致該字段的驗證失敗。如果驗證通過，則規(guī)則將不執(zhí)行任何操作，我們可以繼續(xù)使用我們的應用。

現(xiàn)在我們已經(jīng)創(chuàng)建了規(guī)則，我們可以像這樣在應用中使用它：

{
  "message": "The title field is required. (and 1 more error)",
  "errors": {
    "title": [
      "The title field is required."
    ],
    "description": [
      "The description field is required."
    ]
  }
}

盡管這是我們?yōu)檠菔灸康亩鴦?chuàng)建的簡單規(guī)則，但希望這能讓您了解如何為您的應用構建更復雜的規(guī)則。

測試您自己的驗證規(guī)則

就像應用中的任何其他代碼一樣，重要的是要測試您的驗證規(guī)則以確保它們按預期工作。否則，您可能會冒使用不按預期工作的規(guī)則的風險。

為了了解如何做到這一點，讓我們來看看如何測試我們在上一節(jié)中創(chuàng)建的回文規(guī)則。

對于此特定規(guī)則，我們要測試兩種情況：

當值為回文時，規(guī)則通過。
當值不是回文時，規(guī)則失敗。

在更復雜的規(guī)則中，您可能會有更多的情況，但出于本文的目的，我們將其保持簡單。

我們將在 tests/Unit/Rules 目錄中創(chuàng)建一個名為 PalindromeTest.php 的新測試文件。

讓我們來看看測試文件，然后我們將討論正在執(zhí)行的操作：

<input type="number" min="1" max="10" required>

在上面的測試文件中，我們定義了兩個測試：rule_passes_with_a_valid_value 和 rule_fails_with_an_invalid_value。

正如測試名稱所暗示的那樣，第一個測試確保當值為回文時規(guī)則通過，第二個測試確保當值不是回文時規(guī)則失敗。

我們使用 PHPUnitFrameworkAttributesDataProvider 屬性為測試提供有效值和無效值的列表以進行測試。這是保持測試整潔并能夠使用相同測試檢查多個值的好方法。例如，如果有人向 validValues 方法添加新的有效值，則測試將自動針對該值運行。

在 rule_passes_with_a_valid_value 測試中，我們使用有效值調用規(guī)則上的 validate 方法。我們將閉包傳遞給 fail 參數(shù)（如果規(guī)則內部驗證失敗，則調用此參數(shù)）。我們已指定如果執(zhí)行閉包（即驗證失?。瑒t測試應失敗。如果我們在沒有執(zhí)行閉包的情況下到達測試的結尾，那么我們就知道規(guī)則通過了，并且可以添加簡單的斷言 assertTrue(true) 來通過測試。

在 rule_fails_with_an_invalid_value 測試中，我們與第一個測試一樣，但這次我們將無效值傳遞給規(guī)則。我們已指定如果執(zhí)行閉包（即驗證失?。?，則測試應通過，因為我們期望調用閉包。如果我們在沒有執(zhí)行閉包的情況下到達測試的結尾，則不會執(zhí)行任何斷言，并且 PHPUnit 應該為我們觸發(fā)警告。但是，如果您更喜歡更明確地確保測試失敗而不是僅僅給出錯誤，您可能需要采取略微不同的方法來編寫測試。