PHPUnit 自動化測試大作戰【CH26】

更新於 發佈於 閱讀時間約 15 分鐘

前2篇,我們探討了「網站文章」的情境題;今明兩天,就讓我們探討另一個情境題「會員註冊」吧!

這邊我們同樣假設網站是採前後端分離的設計,因此我們就專注在測試 API 的部分,不過會多一個「註冊驗證信」的部分要實作與做測試驗證。

使用案例

  1. 使用者可填寫註冊資料後送出資料。
  2. 使用者可收到註冊驗證信,且該信件內含有專屬於該使用者的驗證連結。
  3. 使用者點選註冊驗證信中的驗證連結後,將驗證成功,其帳號驗證狀態將轉為已驗證。

這邊我們使用驗證時間來取代驗證狀態,並以有無驗證時間來判斷是否已驗證

依據以上的使用案例,我們可規畫出以下 API / 功能:

API / 功能規畫

  1. 使用者註冊端點 POST /registers
  2. 使用者驗證端點 GET /users/{id}/validation?token={token}
  3. 註冊驗證信

接著就來實作 API 與註冊驗證信的邏輯吧!

實作

  • database/migrations/2014_10_12_000000_create_users_table.php
<?php

use Illuminate\Database\Migrations\Migration;

use Illuminate\Database\Schema\Blueprint;

use Illuminate\Support\Facades\Schema;

return new class extends Migration{

/** * Run the migrations. * * @return void */

public function up() {

Schema::create('users', function (Blueprint $table) {

$table->id();

$table->string('name');

$table->string('email')->unique();

$table->timestamp('email_verified_at')->nullable();

$table->string('password');

$table->string('verify_email_token', 128)->nullable();

$table->rememberToken();

$table->timestamps();

}); } /** * Reverse the migrations. * * @return void */

public function down() {

Schema::dropIfExists('users');

}};
  • app/Models/User.php
<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;

use Illuminate\Foundation\Auth\User as Authenticatable;

use Illuminate\Notifications\Notifiable;

use Laravel\Sanctum\HasApiTokens;

class User extends Authenticatable{

use HasApiTokens, HasFactory, Notifiable;

/** * The attributes that are mass assignable. * * @var array<int, string> */

protected $fillable = [

'name',

'email',

'password',

'email_verified_at',

'verify_email_token',

]; /** * The attributes that should be hidden for serialization. * * @var array<int, string> */

protected $hidden = [

'password',

'remember_token',

]; /** * The attributes that should be cast. * * @var array<string, string> */

protected $casts = [

'email_verified_at' => 'datetime',

];}
  • routes/web.php
<?php

use App\Http\Controllers\UserController;

use Illuminate\Support\Facades\Route;

Route::post('/register', [UserController::class, 'register'])

->name('register');

Route::get('/verify-user-email', [UserController::class, 'verifyUserEmail'])

->name('verify-user-email');
  • app/Http/Controllers/UserController.php
<?php

namespace App\Http\Controllers;

use App\Mail\VerifyUserMail;

use App\Models\User;

use Illuminate\Http\Request;

use Illuminate\Support\Facades\Hash;

use Illuminate\Support\Facades\Mail;

use Illuminate\Support\Str;

class UserController extends Controller{

public function register(Request $request) {

$request->validate([

'name' => 'required',

'email' => 'required',

'password' => 'required',

]); $user = User::create([

'name' => $request->input('name'),

'email' => $request->input('email'),

'password' => Hash::make($request->input('password')),

'verify_email_token' => Str::random(128),

]); Mail::to($user->email)

->send(new VerifyUserMail($user));

return response()->json('');

} public function verifyUserEmail(Request $request) {

$request->validate([

'token' => 'required',

]); $token = $request->input('token');

$user = User::where('verify_email_token', $token)->first();

if (empty($user)) {

return response('Failed', 404);

} $user->email_verified_at = now();

$user->save();

return response('Success');

}}
  • app/Mail/VerifyUserMail.php
<?php

namespace App\Mail;

use App\Models\User;

use Illuminate\Bus\Queueable;

use Illuminate\Contracts\Queue\ShouldQueue;

use Illuminate\Mail\Mailable;

use Illuminate\Queue\SerializesModels;

class VerifyUserMail extends Mailable{

use Queueable, SerializesModels;

private $user;

/** * Create a new message instance. * * @return void */

public function __construct(User $user) {

$this->user = $user;

} /** * Build the message. * * @return $this */

public function build() {

$data = [

'verifyLink' => route('verify-user-email', ['token' => $this->user->verify_email_token]),

]; return $this->with($data)

->view('view.mail.verify-email');

}}
  • resources/views/mail/verify-email.blade.php
<!DOCTYPE html>

<html >

<head>

<meta charset="utf-8">

<meta name="viewport" content="width=device-width, initial-scale=1">

<title>Verify Mail</title>

</head>

<body class="antialiased">

<a href="{{ $verifyLink }}">Verify Your Email</a>

</body>

</html>

前置準備

這邊我們要準備的是User 的 Factory 類別:

  • User Factory
<?php

namespace Database\Factories;

use Illuminate\Support\Str;

use Illuminate\Database\Eloquent\Factories\Factory;

class UserFactory extends Factory{

/** * Define the model's default state. * * @return array */

public function definition(): array {

return [

'name' => $this->faker->name,

'email' => $this->faker->safeEmail,

'password' => bcrypt($this->faker->password),

'remember_token' => Str::random(10),

'verify_email_token' => Str::random(128),

]; }

到這邊為止,我們已經把測試目標準備好了,下一篇我們就來針對各使用案例來寫測試吧!

如果您喜歡這篇文章,歡迎加入追蹤以接收新文章通知 😄

本系列文章目錄

avatar-img
8會員
313內容數
歡迎來到 WilliamP 的沙龍天地,在這裡將與各位讀者探討各種主題,包刮高中數學題庫、PHP開發經驗、LINE聊天機器人開發經驗、書摘筆記等,歡迎交流!
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
WilliamP的沙龍 的其他內容
今天就讓我們依照前一天的情境題,來撰寫測試案例函數吧! 先讓我們規畫擬訂測試案例: 測試案例 當使用者瀏覽文章清單頁時: 使用者可看到所有文章清單,也就是【文章清單API】要能確實將資料庫內的文章資料,筆數不多不少地回應出來。 當使用者瀏覽單一文章頁時: 使用者可看到該文章資料,也就是【
在前面的篇幅中,與大家分享了許多撰寫 PHPUnit 測試程式碼所需的知識,之後的文章就讓我們來來模擬一些情境題,並在這些情境題底下,實際去設計測試案例函數吧! 作為第一個情境題,我們就選「網站文章」來當作第一個挑戰吧! 這邊我們假設網站是採前後端分離的設計,因此我們就專注在測試 API 的部分
今天我們來聊聊覆蓋率報告吧! 何為覆蓋率報告 & 為何需要覆蓋率報告 所謂的覆蓋率報告,指的是能指出我們的專案程式庫,有被測試程式碼實際測試到的部分的佔比有多少。當我們了解有多少程式碼有被覆蓋到,以及有多少程式碼沒被覆蓋到時,理論上我們可以對程式碼是否可正常運作更有信心! 事前準備 先將以
今天讓我們來看 phpunit.xml 吧! phpunit.xml 位在 Laravel 專案根目錄底下,顧名思義,它是一個設定 PHPUnit 執行方式的設定XML檔,PHPUnit 提供了不少設定值可供設定,這邊只提最重要的幾個: stopOnFailure 說明:當此欄位設定為 tru
今天要來為大家介紹 Storage Mocking 及 HTTP Mocking! Storage Mocking 函數 Storage::fake():當我們希望在執行測試目標行為時,想驗證 Storage 各類行為是否符合預期,但又不要真的增刪改檔案時,可在測試程式碼中呼叫此函數。 Upl
今天來看 Queue Mocking 吧! Queue Mocking 函數 Queue::fake():當我們希望在執行測試目標行為時,想驗證某個 Job 類別是否有被派送至佇列中,但又不要真的觸發 Job 入列時,可在測試程式碼中呼叫此函數。 Queue::assertPushed():可
今天就讓我們依照前一天的情境題,來撰寫測試案例函數吧! 先讓我們規畫擬訂測試案例: 測試案例 當使用者瀏覽文章清單頁時: 使用者可看到所有文章清單,也就是【文章清單API】要能確實將資料庫內的文章資料,筆數不多不少地回應出來。 當使用者瀏覽單一文章頁時: 使用者可看到該文章資料,也就是【
在前面的篇幅中,與大家分享了許多撰寫 PHPUnit 測試程式碼所需的知識,之後的文章就讓我們來來模擬一些情境題,並在這些情境題底下,實際去設計測試案例函數吧! 作為第一個情境題,我們就選「網站文章」來當作第一個挑戰吧! 這邊我們假設網站是採前後端分離的設計,因此我們就專注在測試 API 的部分
今天我們來聊聊覆蓋率報告吧! 何為覆蓋率報告 & 為何需要覆蓋率報告 所謂的覆蓋率報告,指的是能指出我們的專案程式庫,有被測試程式碼實際測試到的部分的佔比有多少。當我們了解有多少程式碼有被覆蓋到,以及有多少程式碼沒被覆蓋到時,理論上我們可以對程式碼是否可正常運作更有信心! 事前準備 先將以
今天讓我們來看 phpunit.xml 吧! phpunit.xml 位在 Laravel 專案根目錄底下,顧名思義,它是一個設定 PHPUnit 執行方式的設定XML檔,PHPUnit 提供了不少設定值可供設定,這邊只提最重要的幾個: stopOnFailure 說明:當此欄位設定為 tru
今天要來為大家介紹 Storage Mocking 及 HTTP Mocking! Storage Mocking 函數 Storage::fake():當我們希望在執行測試目標行為時,想驗證 Storage 各類行為是否符合預期,但又不要真的增刪改檔案時,可在測試程式碼中呼叫此函數。 Upl
今天來看 Queue Mocking 吧! Queue Mocking 函數 Queue::fake():當我們希望在執行測試目標行為時,想驗證某個 Job 類別是否有被派送至佇列中,但又不要真的觸發 Job 入列時,可在測試程式碼中呼叫此函數。 Queue::assertPushed():可
你可能也想看
Google News 追蹤
Thumbnail
現代社會跟以前不同了,人人都有一支手機,只要打開就可以獲得各種資訊。過去想要辦卡或是開戶就要跑一趟銀行,然而如今科技快速發展之下,金融App無聲無息地進到你生活中。但同樣的,每一家銀行都有自己的App時,我們又該如何選擇呢?(本文係由國泰世華銀行邀約) 今天我會用不同角度帶大家看這款國泰世華CUB
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
Thumbnail
可能包含敏感內容
先說一下我的背景,非本科系從 2022/3 開始接觸到前端領域,在摸索過程中遇到六角學院,買了 HTML 和 CSS 課程從基礎學起。
測試網站和應用程式時需要注意以下事項和執行以下工作: 注意事項: 跨平台相容性: 確保網站或應用程式在各種瀏覽器和設備上的相容性,包括桌面、平板和手機等。 響應式設計測試: 測試網站或應用程式在不同螢幕尺寸和解析度下的表現,確保響應式設計正常運作。 安全性測試: 確保網站或應用程式的安全性,
Thumbnail
這是一篇很精彩的測試文章喔!
Thumbnail
現代社會跟以前不同了,人人都有一支手機,只要打開就可以獲得各種資訊。過去想要辦卡或是開戶就要跑一趟銀行,然而如今科技快速發展之下,金融App無聲無息地進到你生活中。但同樣的,每一家銀行都有自己的App時,我們又該如何選擇呢?(本文係由國泰世華銀行邀約) 今天我會用不同角度帶大家看這款國泰世華CUB
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
Thumbnail
可能包含敏感內容
先說一下我的背景,非本科系從 2022/3 開始接觸到前端領域,在摸索過程中遇到六角學院,買了 HTML 和 CSS 課程從基礎學起。
測試網站和應用程式時需要注意以下事項和執行以下工作: 注意事項: 跨平台相容性: 確保網站或應用程式在各種瀏覽器和設備上的相容性,包括桌面、平板和手機等。 響應式設計測試: 測試網站或應用程式在不同螢幕尺寸和解析度下的表現,確保響應式設計正常運作。 安全性測試: 確保網站或應用程式的安全性,
Thumbnail
這是一篇很精彩的測試文章喔!