簡單的 11 步在 Laravel 中實現測試驅動開發

KevinYan發表於2018-07-17

測試驅動開發（英語：Test-driven development，縮寫為TDD）是一種軟體開發過程中的應用方法，由極限程式設計中倡導，以其倡導先寫測試程式，然後編碼實現其功能得名。

下文是我在Medium上看到的一篇文章講述瞭如何在Laravel中實現測試驅動開發，我自己已經在專案中實現了測試驅動開發，並且通過持續整合完成了專案的自動測試，文章中有些我認為需要改進的地方也註明了，希望這篇文章能幫助到那些想寫測試用例但是一直覺得無從下手的開發者們。文章一共有四篇，之後計劃都翻譯出來給大家參考。

原文連結: https://medium.com/@jsdecena/simple-tdd-in-laravel-with-11-steps-c475f8b1b214

前言

大多數Web開發工程師第一次聽到TTD(test driven development)測試驅動開發的時候都會感到畏懼，我也一樣。當你剛開始試著進行測試驅動開發時你會感到很崩潰，但是如果你抗拒它就很難真正學會並掌握它。在本文中我會介紹如何在Laravel中進行測試驅動開發。

Note: 這篇文章時針對API響應的TDD. 如果你想看與Laravel blade相關的功能測試請看這篇文章 (還未來得及翻譯，訪問需要科學上網), head up on this article.

step 1: 準備Laravel測試套件

在專案根目錄中，更新phpunit.xml檔案的如下專案:

<env name="DB_CONNECTION" value="sqlite"/>
<env name="DB_DATABASE" value=":memory:"/>
<env name="API_DEBUG" value="false"/>
<ini name="memory_limit" value="512M" />

更新完後phpunit.xml檔案會像下面這樣:

<?xml version="1.0" encoding="UTF-8"?>
<phpunit backupGlobals="false"
         backupStaticAttributes="false"
         bootstrap="vendor/autoload.php"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false">
    <testsuites>
        <testsuite name="Feature">
            <directory suffix="Test.php">./tests/Feature</directory>
        </testsuite>

        <testsuite name="Unit">
            <directory suffix="Test.php">./tests/Unit</directory>
        </testsuite>
    </testsuites>
    <filter>
        <whitelist processUncoveredFilesFromWhitelist="true">
            <directory suffix=".php">./app</directory>
        </whitelist>
    </filter>
    <php>
        <env name="APP_ENV" value="testing"/>
        <env name="CACHE_DRIVER" value="array"/>
        <env name="SESSION_DRIVER" value="array"/>
        <env name="QUEUE_DRIVER" value="sync"/>
        <env name="DB_CONNECTION" value="sqlite"/>
        <env name="DB_DATABASE" value=":memory:"/>
        <env name="APP_DEBUG" value="false"/>
        <env name="MAIL_DRIVER" value="log"/>
        <ini name="memory_limit" value="512M" />
    </php>
</phpunit>

我們只需要在記憶體中進行測試這樣測試執行的速度會快一些，所以在database配置專案中我們將使用sqlite和:memory: (Sqlite的記憶體資料庫)。將APP_DEBUG設定為false因為我們只需要對真實產生的錯誤進行斷言。隨著專案迭代測試用例會越來越多所以在將來你可能會需要增加memory_limit的值。

譯者注: APP_DEBUG建議不要改成false，這樣有助於讓我們的程式碼寫的更嚴謹

在Laravel裡測試用例的基類TestCase中作一些測試相關的準備:

<?php
namespace Tests;
use Illuminate\Foundation\Testing\DatabaseMigrations;
use Illuminate\Foundation\Testing\DatabaseTransactions;
use Illuminate\Foundation\Testing\TestCase as BaseTestCase;
use Faker\Factory as Faker;
/**
 * Class TestCase
 * @package Tests
 * @runTestsInSeparateProcesses
 * @preserveGlobalState disabled
 */
abstract class TestCase extends BaseTestCase
{
    use CreatesApplication, DatabaseMigrations, DatabaseTransactions;
    protected $faker;
    /**
     * Set up the test
     */
    public function setUp()
    {
        parent::setUp();
        $this->faker = Faker::create();
    }
    /**
     * Reset the migrations
     */
    public function tearDown()
    {
        $this->artisan('migrate:reset');
        parent::tearDown();
    }
}

我們需要在TestCase中use DatabaseMigrations這個trait這樣在執行每個測試用例時，遷移檔案都會被執行一遍，於此同時在setUp()和tearDown()方法中我們需要執行建立測試環境和清理測試環境的相關操作。

譯者注： DatabaseMigrations這個性狀在測試setUp階段會執行migrate:refresh, 清除所有表然後重新執行遷移，其實我們重置資料庫後需要通過seeder來填充測試資料，所以我更傾向於不使用這個遷移而是在TestCase的setUp中使用migrate:refresh —seeder 來完成重置資料庫和填充測試資料的操作

Step2：寫測試用例

就像鮑勃大叔說的那樣：”除非先寫測試用例否則你沒有權利去寫實現程式碼（implementation）“。現在開始寫我們的測試吧。（測試驅動開發的第一天原則)

為了讓phpunit識別測試，需要在測試方法上新增/ @test /註釋，或者是測試方法命名以test字首開頭。

<?php
namespace Tests\Unit;
use Tests\TestCase;
class ArticleApiUnitTest extends TestCase
{
  public function it_can_create_an_article()
  {
      $data = [
        'title' => $this->faker->sentence,
        'content' => $this->faker->paragraph
      ];

      $this->post(route('articles.store'), $data)
        ->assertStatus(201)
        ->assertJson($data);
  }
}

在這個測試中，測試了是否能建立一篇文章，我們斷言了在建立文章成功後應用將返回201狀態碼還有預期的JSON資料。

在建立好我們的第一個測試後，執行phpunit或者vendor/bin/phpunit

當我們執行phpunit後測試結果顯示失敗了，這很正常因為在測試驅動開發中我們是先寫測試程式，然後在編碼實現功能的，所以在建立測試程式伊始測試程式執行後的結果就是測試失敗(測試驅動開發的第二條原則)。在測試中我們斷言應用會返回201狀態碼但是卻返回了404，為什麼? 因為測試中請求的URL還未在應用中建立。這個api/v1/articles POST路由在應用中並不存在所以針對這個請求應用丟擲了404錯誤。

接下來我們該作什麼？

Step 3: 在路由檔案中建立測試裡請求的URL

讓我們建立測試裡請求的這個URL看看接下來會發生什麼。

在你專案中的routes/api.php檔案中建立這個URL，在api中的路由其URL會自動加上/api字首。

<?php
use App\Http\Controllers\Api\ArticlesApiController;
use Illuminate\Support\Facades\Route;
Route::group(['prefix' => 'v1'], function () {
  Route::resource('articles', ArticlesApiController::class);
});

你可以通過artisan命令建立這個資源控制器:

php artisan make:controller Api/ArticlesApiController —-resource

也可以手動建立。POST請求將會路由到ArticlesApiContorller的store方法

Step 4: DEBUG 控制器

<?php
namespace App\Http\Controllers\Api;
class ArticlesApiController extends Controller 
{
    public function store() {
        dd('success!');
    }
}

現在讓我們執行測試程式，看看測試程式是否能夠訪問到應用的這一部分，再次執行phpunit後返回結果如下：

執行後的結果在終端中提示出了字串success!這意味著測試程式成功地訪問到了建立文章的API。

Step 5: 驗證你的輸入

不要忘記驗證將要儲存到資料庫中的資料，所以現在我們建立一個CreateArticleRequest類來控制輸入資料的驗證。

<?php
namespace App\Http\Controllers\Api;
class ArticlesApiController extends Controller 
{
    public function store(CreateArticleRequest $request) {
        dd('success!');
    }
}

這個請求類包含了資料驗證的規則:

<?php
namespace App\Articles\Requests;
use Illuminate\Foundation\Http\FormRequest;
class CreateArticleRequest extends FormRequest
{
    /**
     * Transform the error messages into JSON
     *
     * @param array $errors
     * @return \Illuminate\Http\JsonResponse
     */
    public function response(array $errors)
    {
        return response()->json($errors, 422);
    }
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }
    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'title' => ['required'],
            'content' => ['required']
        ];
    }
}

這是一個很好的驗證資料的方式，因為之後我們可以新建另外一個測試程式來測試是否能捕獲到這些驗證錯誤，不過為了文章的精簡我會在另外一篇單獨的文章裡來講述如何建立捕獲錯誤的測試程式。

Step 6: 返回剛才建立的資料

記住在相應中應該返回指定的JSON結構這樣我們就知道新建的資料成功儲存到了資料庫中。所以我們應該返回新建立的文章物件來滿足我們上面建立的測試程式。

<?php
namespace App\Http\Controllers\Api;
class ArticlesApiController extends Controller 
{
    /**
    * @param CreateArticleRequest $request
    */
    public function store(CreateArticleRequest $request) {
      return Article::create($request->all());
    }
}

你可能已經已經注意到了我們還沒有建立Article這個類，接下來讓我們來建立這個Model。

Step 7: 建立模型類

<?php
namespace App\Articles;
use Illuminate\Database\Eloquent\Model;
class Article extends Model 
{
  protected $fillable = [
    'title',
    'content'
  ];

}

在Article這個模型類中，你需要定義可填充和序列化時需要被隱藏的欄位，一旦Article類定義好後，返回到控制器中匯入這個Article類。

<?php
namespace App\Http\Controllers\Api;
use App\Articles\Article;
class ArticlesApiController extends Controller 
{
    /**
    * @param CreateArticleRequest $request
    */
    public function store(CreateArticleRequest $request) {
      return Article::create($request->all());
    }
}

我們差不多快要完成了！測試程式正確建立好了，URL已經建立並且能夠訪問了，處理URL請求的控制器程式還有與資料表對應的模型類也都已經就緒了，現在讓我們再試著執行一次phpunit命令。

Step 8: 再次執行phpunit看看結果會怎麼樣

它再一次失敗了，這是好事還是壞事？可以說即是好事也是壞事。好的一方面是測試中斷言會返回201狀態碼的URL的返回結果從之前的404錯誤變成了500錯誤(如果你注意到了)。

不好的一方面是，它測試失敗了我們需要讓程式能夠正確通過測試程式。當我們想要debug時我們想要看看應用程式到底丟擲了什麼錯誤。在Laravel測試程式中你只需要在發出POST請求後在呼叫dump()方法就能夠看到應用程式返回的響應。


<?php
namespace Tests\Unit;
use Tests\TestCase;
class ArticleApiUnitTest extends TestCase
{
  public function it_can_create_an_article()
  {
      $data = [
        'title' => $this->faker->sentence,
        'content' => $this->faker->paragraph
      ];

      $this->post(route('articles.store'), $data)
        ->dump()
        ->assertStatus(201)
        ->assertJson($data);
  }
}

你可以進一步debug POST請求後的輸出，沒準會得到更多你需要的資訊，如果沒有明確地給出提示發生了什麼才導致的這個錯誤你可以去Laravel應用的日誌檔案/storage/logs/laravel.log裡去查詢錯誤資訊。

現在讓我們檢查一下為什麼會返回500錯誤。

Well，因為我們在請求中正在嘗試向一個不存在的資料表中寫入資料所以才請求才會返回500錯誤。

Step 9: 建立資料表

執行下面的laravel artisan命令：

php artisan make:migration create_articles_table –create=articles

Laravel會自動在/database/migrations裡來建立遷移檔案。

<?php
use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreateArticlesTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('articles', function (Blueprint $table) {
            $table->increments('id');
            $table->string('title');
            $table->text('content');
            $table->timestamps();
        });
    }
    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('articles');
    }
}

預設遷移建立的資料表中只有id和時間欄位，你需要根據需求新增需要的欄位。

Step 10: 再一次執行phpunit

我們快要大功告成了，文章開始時我們承諾了完成TDD有11個步驟，現在是步驟10了！你需要輕輕拍下你的被來鼓勵自己已經走到了這裡。

Ooops, 又失敗了？Whyyyyyyy? 如果你仔細檢查的話你會發現你處在正確的軌道上！響應的狀態碼從500又變成200。這意味著在發出POST請求後應用返回了執行成功的響應！這是沒有匹配我們的需求，我們需要應用返回的響應狀態碼為201來讓我們知道文章資料已經被正確寫入到了資料庫中。所以我們只需要修改一下我們的控制器程式為:

<?php
namespace App\Http\Controllers\Api;
use App\Articles\Article;
class ArticlesApiController extends Controller 
{
    /**
    * @param CreateArticleRequest $request
    */
    public function store(CreateArticleRequest $request) {
      return response(Article::create($request->all()), 201);
    }
}

Step 11: 執行phpunit然後祈禱一切會好

恭喜大功告成！你成功讓程式通過了測試，這就是測試驅動開發的第三條原則。

這就是測試驅動開發(TDD)在Laravel中的簡單實現。還有其它的一些方法在這篇文章中沒有來得及講到，我在未來可能會那些，像是repository pattern等等。repository pattern是DDD (domain driven development)領域驅動開發的最佳實踐。

測試驅動開發還有很多方法這裡沒有設計到不過我覺得這篇文章已經足夠讓你開始試著在實踐中應用測試驅動開發了。

譯者注

通過文章總結起來測試驅動開發有三條原則：

倡導先寫測試程式，再編碼實現功能。
測試程式建立伊始肯定會測試失敗。
在讓測試程式測試成功的過程中逐步編碼實現功能

關注微信公眾號網管叨bi叨不錯過每一篇好文

簡單的11步在Laravel中實現測試驅動開發
2019-02-27
Laravel
Laravel 測試驅動開發 -- 正向單元測試
2018-07-25
Laravel
測試驅動開發在專案中的實踐
2020-12-07
TDD---測試驅動開發,簡單的一點認識
2007-12-26
行為驅動開發在 Python 開發測試中的應用
2015-10-28
Python
"測試"驅動開發
2010-12-29
談“測試驅動的開發”
2020-04-06
【敏捷開發】驅動測試開發
2014-03-14
敏捷
使用 TDD 測試驅動開發來構建 Laravel REST API
2019-03-06
LaravelRESTAPI
測試驅動開發(TDD)的思考
2014-04-06
測試驅動開發(TDD)實戰心得 - DeniMoka
2020-11-17
小議測試驅動開發
2017-07-10
測試開發之單元測試-禪道結合ZTF驅動單元測試執行
2023-05-12
基於Python的測試驅動開發實戰
2015-04-15
Python
測試驅動的Rails開發系列之二——實體
2012-05-25
AI
基於測試驅動的iOS開發
2016-10-25
iOS
面向 C++ 的測試驅動開發
2016-08-11
C++
Python 實現行為驅動開發 (BDD) 自動化測試詳解
2024-07-27
Python
TDD（測試驅動開發）死了嗎？
2019-06-26
你這不是測試驅動開發
2011-08-25
什麼是測試驅動開發
2024-11-03
在.NET開發中的單元測試工具之——NUnit
2014-10-09
變異測試是測試驅動開發（TDD）的演變
2019-10-17
[譯] 通過 Quick 和 Nimble 在 Swift 中進行測試驅動開發
2018-02-26
UISwift
在 Postman 中實現自動化測試的全面指南
2024-03-08
Postman
SOA 環境中的測試驅動的開發，第 1 部分: 測試資料對映
2009-06-03
簡單介紹Angular單元測試之事件觸發的實現
2020-03-09
Angular事件
測試驅動開發(TDD)例項演示
2020-05-14
測試驅動開發到底好不好
2011-10-21
一步一步實現現代前端單元測試
2018-01-18
前端
驅動程式開發步驟
2021-10-19
簡單建立VC + DDK的驅動開發環境
2020-04-04
開發環境
Scrum敏捷軟體開發之技術實踐——測試驅動開發TDD
2015-06-17
Scrum敏捷
是否使用TDD（測試驅動開發）進行UI開發
2015-02-12
UI
測試驅動開發(TDD)跟敏捷開發有衝突
2011-06-29
敏捷
安卓開發中RecycleView簡單使用步驟
2021-01-02
安卓View
Python實現效能自動化測試竟然如此簡單
2019-07-30
Python
文件驅動開發模式在 AIMS 中的應用與實踐
2021-01-26
模式AI