Laravel驗證的最終指南

數據驗證是任何 Web 應用的關鍵組成部分。它有助於防止安全漏洞、數據損壞以及使用用戶輸入時可能出現的各種其他問題。

本文將探討什麼是數據驗證以及它為何如此重要。我們將比較客戶端驗證和服務器端驗證，並解釋為什麼不應僅依賴客戶端驗證。

然後，我們將介紹一些我在 Laravel 應用中常用的便捷驗證規則。最後，我們將學習如何創建自己的驗證規則並進行測試，以確保其按預期工作。

什麼是數據驗證？

---

數據驗證是在嘗試使用數據之前檢查數據有效性的過程。這可以是檢查簡單的項目，例如請求中是否存在必填字段，也可以是更複雜的檢查，例如字段是否與特定模式匹配或在數據庫中是否唯一。

通常，在 Web 應用中驗證數據時，如果數據無效，您需要向用戶返回錯誤消息。

這有助於防止安全漏洞、數據損壞並提高數據準確性。因此，只有在數據有效的情況下，我們才會繼續處理請求。

記住，不能信任來自用戶的任何數據（至少在您驗證它之前！）。

為什麼數據驗證很重要？

---

數據驗證之所以重要，原因有很多，包括：

# 提升安全性

在您的應用中驗證數據最重要的原因之一是提升安全性。通過在使用數據之前對其進行驗證，您可以降低惡意輸入被用來攻擊您的應用或用戶的可能性。

# 防止存儲不正確的數據

想像一下，我們期望某個字段是整數，但用戶卻傳遞了一個文件。當我們嘗試在應用的其他地方使用該數據時，這可能會導致各種問題。

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

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

# 確保 Artisan 命令輸入正確

除了能夠驗證 HTTP 請求中傳遞的數據外，您還可以驗證 Artisan 命令。這可以防止開發人員意外輸入無效值並導致應用出現問題。

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

---

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

# 客戶端驗證

客戶端驗證是在將數據發送到服務器之前在瀏覽器中執行的驗證。它可以使用 JavaScript 甚至 HTML 屬性來實現。

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

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

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

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

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

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

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

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

# 服務器端驗證

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

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

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

Laravel 如何處理驗證

---

現在我們已經了解了什麼是驗證以及它為什麼重要，讓我們來看看如何在 Laravel 中使用它。

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

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

• 手動驗證數據
• 使用表單請求類驗證數據

# 手動驗證數據

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

然後，我們可以將兩個參數傳遞給 make 方法：

• data - 我們要驗證的數據
• rules - 我們要根據其驗證數據的規則

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

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

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

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

創建驗證器後，我們可以調用返回的 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 方法將引發 IlluminateValidationValidationException。 Laravel 將根據所進行的請求類型自動處理此異常（假設您沒有更改應用中的默認異常處理）。如果請求是 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();

# 使用表單請求類驗證數據

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

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

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

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

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

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

現在讓我們來看看 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：此方法用於確定用戶是否有權發出請求。如果該方法返回 false，則會向用戶返回 403 Forbidden 響應。如果該方法返回 true，則將運行驗證規則。
• rules：此方法用於定義應在請求上運行的驗證規則。該方法應返回一個應在請求上運行的規則數組。

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

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

Laravel 中常用的驗證規則

---

正如我已經提到的，Laravel 驗證系統非常強大，可以輕鬆地將驗證添加到您的應用中。

在本節中，我們將快速介紹一些我喜歡的便捷驗證規則，我認為大多數用戶都會發現它們在他們的應用中很有用。

如果您有興趣查看 Laravel 中可用的所有規則，可以在 Laravel 文檔中找到它們：https://www.php.cn/link/45d5c43856059a4f97d43d6534be52d0

# 驗證數組

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

讓我們來看一個如何驗證數組的示例，然後我們將討論正在執行的操作：

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

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

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

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

通過能夠在驗證規則中使用 * 通配符，我們可以輕鬆驗證應用中的數據數組。

# 驗證日期

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

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 規則：

$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 規則：

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

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

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

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

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

# 驗證密碼

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

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

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

• 至少 8 個字符長
• 至少包含一個字母
• 至少包含一個大寫字母和一個小寫字母
• 至少包含一個數字
• 至少包含一個符號
• 不是被洩露的密碼（即不在包含其他系統數據洩露中洩露密碼記錄的 Have I Been Pwned 數據庫中）

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

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

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

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

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'],
    ]
);

執行此操作後，我們現在可以在驗證規則中調用 Password::defaults()，並將我們在 AppServiceProvider 中指定的規則用於：

$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()) {
    // 一个或多个字段验证失败。
    // 在此处进行处理...
}

# 驗證顏色

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

過去，我不得不使用正則表達式（我承認我不太了解）來驗證顏色是否為十六進制格式的有效顏色（例如 #FF00FF）。但是，Laravel 現在有一個方便的 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 提供了一些您可以使用的文件驗證規則。

假設您想允許用戶上傳 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 中上傳文件》文章，該文章向您展示瞭如何執行此操作、您可能需要採取的不同驗證方法以及如何對其進行測試。

# 驗證數據庫中是否存在字段

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

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

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

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 數組中傳遞的每個 ID 是否都存在於 users 表的 id 列中。

這是確保您正在使用的數據有效並且在嘗試使用它之前存在於數據庫中的一種好方法。

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

$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 數組中傳遞的每個 ID 是否都存在於 users 表的 id 列中，並且用戶的 is_verified 列設置為 true。因此，如果我們傳遞未經驗證的用戶 ID，則驗證將失敗。

# 驗證數據庫中字段的唯一性

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

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

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 列上是唯一的。

但是，如果我們嘗試在用戶可以更新其電子郵件地址的個人資料頁面上使用此驗證，會發生什麼情況？驗證將失敗，因為 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 方法中。相反，您只應傳遞系統生成的唯一 ID，例如來自 Eloquent 模型實例的自增 ID 或 UUID。否則，您的應用將容易受到 SQL 注入攻擊。"

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

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

創建您自己的驗證規則

---

儘管 Laravel 附帶了大量內置驗證規則，但您可能需要創建自定義驗證規則以適應特定用例。

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

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

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

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

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

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'],
    ]
);

這應該為我們創建了一個新的 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()) {
    // 一个或多个字段验证失败。
    // 在此处进行处理...
}

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

• $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();

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

現在我們已經創建了規則，我們可以像這樣在應用中使用它：

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

儘管這是我們為演示目的而創建的簡單規則，但希望這能讓您了解如何為您的應用構建更複雜的規則。

測試您自己的驗證規則

---

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

為了了解如何做到這一點，讓我們來看看如何測試我們在上一節中創建的回文規則。

對於此特定規則，我們要測試兩種情況：

• 當值為回文時，規則通過。
• 當值不是回文時，規則失敗。

在更複雜的規則中，您可能會有更多的情況，但出於本文的目的，我們將其保持簡單。

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

讓我們來看看測試文件，然後我們將討論正在執行的操作：

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

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

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

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

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

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

結論

---

在本文中，我們研究了什麼是驗證以及它為什麼重要。我們比較了客戶端驗證和服務器端驗證，並探討了為什麼客戶端驗證不應僅用作應用中唯一的驗證形式。

我們還介紹了一些我喜歡在我的 Laravel 應用中使用的便捷驗證規則。最後，我們探討瞭如何創建您自己的驗證規則並對其進行測試以確保其按預期工作。

希望您現在應該有足夠的信心開始使用更多驗證來提高應用的安全性和可靠性。

以上是Laravel驗證的最終指南的詳細內容。更多資訊請關注PHP中文網其他相關文章！