在解決幾個問題後，我發現其實做法並不難，所以接下來我就來介紹幾個測試 closure 的方式。

範例

先來看看一個簡單的 closure 使用範例：

class Example
{
    public function runClosure(Closure $closure)
    {
        $closure();
    }
}

在 Example::runClosure 方法中接受了一個 $closure 參數，而它的型別屬於 Closure 類別，使我們可以直接在程式裡用 $closure() 的方式來執行它的內容。

測試則是這樣寫的：

class ExampleTest extends PHPUnit_Framework_TestCase
{
    public function testRunClosure()
    {
        $example = new Example();

        $closure = function () {};
        $example->runClosure($closure);
    }
}

在測試中，我們傳入一個 anonymous function 給目標物件的 runClosure 方法使用。在 PHP 中， closure 和 anonymous function 其實是一樣的，它們最後都會轉化成 Closure 物件；這點和 JavaScript 不同，要特別注意。

問題來了，我們怎麼驗證 $closure 被呼叫了呢？

遇到的問題

我第一個想法是使用 Mockery 來將 anonymous function 包起來，看看 PHP 底層會呼叫 closure 的哪個函式，我再做 shouldReceive 驗證：

$closure = Mockery::mock(function () {});
$example->runClosure($closure);

結果執行測試時，出現了以下錯誤訊息：

Argument 1 passed to Example::runClosure() must be an instance of Closure, instance of Mockery_0_Closure_Closure given

這就奇怪了， Mockery 所 mock 出來的物件，類型應該是 Closure 的子類別呀？為什麼會被 type hint 打槍呢？

帶著疑惑，我試著直接 mock Closure 類別：

$closure = Mockery::mock(Closure::class);
$example->runClosure($closure);

錯誤訊息變成了：

Mockery\Exception: The class \Closure is marked final and its methods cannot be replaced. Classes marked final can be passed in to \Mockery::mock() as instantiated objects to create a partial mock, but only if the mock is not subject to type hinting checks.

原來問題就出在於 Closure 類別在 PHP 中是被宣告為 final ，也就是無法再被繼承。而 Mockery 遇到這樣的類別，官方的建議是：

The simplest solution is not to mark classes or methods as final!

就是不要用 final 啦！可是 Closure 是 PHP 的內建類別，沒辦法把 final 拿掉，這樣一來不就無解了？

注入 spy 物件來驗證

其實轉個念頭，因為傳入待測程式的 closure 內容是我可以控制的，所以我不一定要去 mock closure ，而是讓它實際跑跑看，然後驗證裡面的程式碼是否有被執行就可以了。而最簡單的方法，就是插入一個 spy 物件，透過它來得知 closure 是否有被執行。

我在測試案例裡 mock 了 stdClass 這個標準類別，然後放在 $spy 這個變數裡；然後告訴它應該要接收到 detected 這個方法被執行一次的資訊。最後把這個 $spy 變數注入 closure 裡，在裡面執行 detected 方法：

public function testRunClosure()
{
    $spy = Mockery::mock(stdClass::class);
    $example = new Example();
    
    $spy->shouldReceive('detected')->once();
    
    $example->runClosure(function () use ($spy) {
        $spy->detected();
    });
}

這樣一來就可以透過 Spy 物件來驗證 closure 是否有被執行了。

驗證注入目標物件的 closure

不過有時候我們會希望在 closure 裡使用目標物件，例如：

class Example
{
    public function runClosure(Closure $closure)
    {
        $closure($this);
    }
}

這時 closure 就可以將目標物件當做參數注入，然後再執行它的方法。例如：

$example = new Example();
    
$example->runClosure(function ($target) {
   $target->otherMethod();
});

但我只是要確認目標物件有被正確傳入 closure 中，所以應該要驗證目標物件的類別是 Example 就可以了。我們可以直接在 closure 中使用 $this 來呼叫驗證方法，因為這時的 $this 是指向測試案例的物件。所以測試就可以寫成：

public function testRunClosure()
{
    $example = new Example();

    $example->runClosure(function ($target) {
        $this->assertInstanceOf(Example::class, $target);
    });
}

像這樣的場合就不需要使用 spy 物件了。

驗證使用 bindTo 的 closure

如果在待測目標物件的方法裡，使用 Closure::bindTo 這個方法來重新定義 $this 時，該怎麼測試呢？例如：

public function runClosure(Closure $closure)
{
    $cb = $closure->bindTo($this);
    $cb();
}

注意，這時候 $cb 並不是用注入的參數，而是使用執行時期的 context (也就是 $this ) 來指向目標物件；這也使得我們不能在測試中直接用 $this 來呼叫驗證方法，必須另尋出路。

所幸 PHP 的 closure 還提供了一個 use 的語法，讓我們可以把外部變數帶入 closure 中。但它不能直接帶入 $this ，所以必須換個名字。最後測試就可以改成：

public function testRunClosure()
{
    $assert = $this;
    $example = new Example();

    $example->runClosure(function () use ($assert) {
        $assert->assertInstanceOf(Example::class, $this);
    });
}

總結

closure 是在 PHP 5.3 中就引入的特性，現在越來越多函式庫與框架都已經將它納入設計時的考量了。當你有需要自己設計使用 closure 的方法時，就可以嘗試這些方法來測試 closure ：

1. 使用 anonymous function 時，使用 spy 物件來觀察。
2. 當 closure 會注入目標物件時，直接驗證目標物件的類別。
3. 當 closure 是透過 bindTo 來繫結目標物件時，用 use 來另外傳遞測試案例物件，以便呼叫 assertion 方法驗證。

如果有更好的方法，也歡迎大家建議。

我知道它改起來很痛苦，一堆不良的 PHP 程式習慣都阻礙你的修正；使得每次調整功能時，到底改得對不對，得要等到上線才知道。想要重寫一個新版本，但太多的實作細節你不清楚；也沒有最新的規格文件，讓你無法為新版本做出功能無誤的保證。

現在你唯一擁有的，就是已經在線上運作的程式邏輯；雖然它可能還有 bug ，但至少大多數的功能是通過使用者驗證的。那麼先為它買個保險吧！確保之後的修改不會影響到其他功能的正常運作；而最直接的方式，就是把目前程式邏輯所呈現的結果或是使用者的操作，寫成自動化 Web 測試。

建立 Web 測試的方法有很多，這裡我將介紹我在實務上使用 PHPUnit 加上 Mink 搭配 PhantomJS 的方法。

所需工具與原理

在 Web 測試中，主要分成三個部份：

• 自動化測試框架：負責執行測試案例及驗證
• 瀏覽器控制器或模擬器：透過腳本來操作或模擬瀏覽器的行為
• 目標瀏覽器：就是我們常用的網頁瀏覽器

PHPUnit 是 PHP 中最常見的自動化測試框架，要應用在舊專案中也非常輕鬆。

Mink 扮演的就是控制瀏覽器的角色，它可以透過不同的 Driver 來控制或模擬瀏覽器。

而 PhantomJS 則是一個透過程式來操作的 Headless WebKit 瀏覽器；也因為它沒有視窗介面，所以啟動速度非常快，非常適合用來測試。另外它還內建 GhostDriver ，讓我們可以透過 WebDriver Wire Protocol 來操作它。

所以整個 Web 測試的基礎，就是在 PHPUnit 的測試案例中，透過 Mink 的 Selenium2 Driver 來操作 PhamtomJS 。

接下來就進入實作吧。

工具的安裝

以下介紹的安裝方式，都是在 Mac OS X 環境下完成；其他作業系統的安裝方式也差不多，這裡就不再贅述。

安裝 PHPUnit 與 Mink

先建立一個專案目錄，然後切換到專案目錄下，執行：

composer require phpunit/phpunit behat/mink-selenium2-driver

這樣 Composer 會將 PHPUnit 、 Mink 及 Mink Selenium 2 Driver 安裝在 vendor 目錄下，並自動建立 composer.json 及 composer.lock 兩個檔案。

註：這裡我假設你的環境可以執行 composer 指令，所以也不再贅述 Composer 的安裝流程。

安裝 PhantomJS

接著到 PhantomJS 官網下載 Mac OS X 專用的 ZIP 檔。然後執行：

unzip phantomjs-2.0.0-macosx.zip
sudo mv phantomjs /usr/local/bin/

用以下指令確認有安裝完成：

phantomjs --version

沒問題的話，應該會出現 2.0.0 。

設定專案的 PHPUnit

在專案目錄下新增 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"
         syntaxCheck="false">
    <testsuites>
        <testsuite name="Application Test Suite">
            <directory>./tests/</directory>
        </testsuite>
    </testsuites>
</phpunit>

執行 ./vendor/bin/phpunit ，確認有使用這個設定檔：

PHPUnit 5.0.8 by Sebastian Bergmann and contributors.

Time: 13 ms, Memory: 1.75Mb

No tests executed!

測試實例

簡單介紹撰寫測試案例的步驟：

1. 建立一個 driver 物件，這裡是使用 Selenium2Driver 。
2. 建立一個 session 物件，並透過上面的 driver 物件來操作瀏覽器。
3. 將 session 物件連上指定網址。
4. 從 session 取出 page 物件來操作頁面。
5. 取出 page 物件的狀態或內容來驗證。

詳細的測試寫法可以參考 Mink 官方文件。

以下我示範如何用 Google 來搜尋關鍵字，並驗證搜尋結果有包含我所預期的文字。

先建立 tests 目錄，然後新增一個 tests/GoogleSearchTest.php 檔，內容如下：

<?php
use Behat\Mink\Driver\Selenium2Driver;
use Behat\Mink\Session;

class GoogleSearchTest extends PHPUnit_Framework_TestCase
{
    public function testSearchWithKeyword()
    {
        // 使用 Selenium2Driver 來操作 PhantomJS
        $driver = new Selenium2Driver('phantomjs');

        // 建立一個 Session 物件來控制瀏覧器
        $session = new Session($driver);
        $session->start();

        // 瀏覽 Google 首頁
        $session->visit('https://www.google.com');

        // 操作頁面物件來搜尋關鍵字
        $page = $session->getPage();
        $page->fillField('q', 'Jace Ju');
        $page->find('css', 'form')->submit();

        // 得到搜尋結果後驗證是否包含預期中的文字
        $text = $page->getText();
        $this->assertContains('網站製作學習誌', $text);
    }
}

執行測試

在執行測試之前，需要先啟動 PhantomJS 。 PhantomJS 提供一個 --webdriver 的選項讓它可以啟用遠端 WebDriver 模式，接收測試程式透過 WebDriver API 傳來的要求。另外因為有時測試的網址會包含 SSL ，所以要用 --ssl-protocol=tlsv1 及 --ignore-ssl-errors=true 來確保 SSL 的操作正常。

phantomjs --webdriver=4444 --ssl-protocol=tlsv1 --ignore-ssl-errors=true

PhantomJS 順利啟動後，就可以另開一個 terminal 視窗來進行測試了：

./vendor/bin/phpunit

測試無誤的話會出現以下結果：

PHPUnit 5.0.8 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 2.38 seconds, Memory: 4.50Mb

OK (1 test, 1 assertion)

Page Objects 模式

上面的例子中有個問題：當頁面功能沒有更動，但是 UI 改變時 (例如 DOM 元素或 id/class 名稱) ，我們就必須去更改測試案例的程式碼；而如果同樣的功能在多個測試案例中出現，那麼要改的地方就更多了。所以在實務中，我們會將頁面的功能行為與 UI 細節分離開來，以解決 UI 細節重複的問題；為了這個目標，我們引入 Page Objects 這個模式。

要特別注意的是， Page Objects 模式和 Mink 的 page 物件是兩件事。 Page Objects 模式主要是透過 API 描述頁面的行為，並封裝 UI 細節；而 Mink 的 page 物件則實際上是一個 DocumentElement 物件，主要是用來操作頁面上的元素。換句話說，在 Page Objects 模式中，頁面類別所封裝的 UI 細節，就是用 DocumentElement 物件來操作的。

實作 Page Objects 模式

雖然 Page Objects 模式可以自行實作，但為了省下一些自行撰寫的時間，我特地寫了一個 goez/mink-page-objects 供大家使用。

首先在專案目錄下執行：

$ composer require goez/mink-page-objects --dev

建立一個 tests/bootstrap.php ，內容如下：

<?php
/** @var Composer\Autoload\ClassLoader $loader */
$loader = require __DIR__ . '/../vendor/autoload.php';
$loader->addPsr4('Google\\', __DIR__ . '/Google/');

將 phpunit.xml 中的 vendor/autoload.php ，改為 tests/bootstrap.php 。

將頁面細節封裝在頁面行為功能裡

接下來先建立 tests/Google/Home.php 檔；這是 Google 首頁類別，它繼承抽象的 Page 類別，並提供一個 search 方法：

<?php

namespace Google;

use Goez\PageObjects\Page;

class Home extends Page
{
    protected $parts = [
        'SearchForm' => ['css' => 'form'],
    ];

    public function search($keyword)
    {
        return $this->getPart(SearchForm::class)
            ->search($keyword);
    }
}

接下來我建立一個 tests/Google/SearchForm.php ，它主要是封裝搜尋的操作細節：

<?php

namespace Google;

use Goez\PageObjects\Part;

class SearchForm extends Part
{
    /**
     * @param $keyword
     * @return SearchResult
     * @throws \Behat\Mink\Exception\ElementNotFoundException
     */
    public function search($keyword)
    {
        $this->element->fillField('q', $keyword);
        $this->element->submit();

        return $this->createPage(SearchResult::class);
    }
}

這裡，我把原來輸入關鍵字並送出表單的 UI 操作，封裝在 search 方法中，並回傳一個搜尋結果頁面物件。

再建立 tests/Google/SearchResult.php 檔，它主要是封裝搜尋結果頁。

<?php

namespace Google;

use Goez\PageObjects\Page;

class SearchResult extends Page
{

}

最後就可以把原來的測試案例改用新的頁面類別來重寫了：

<?php

use Behat\Mink\Driver\Selenium2Driver;
use Behat\Mink\Session;
use Goez\PageObjects\Context;
use Goez\PageObjects\Helper\PhantomJSRunner;
use Google\Home;

class GoogleSearchTest extends PHPUnit_Framework_TestCase
{
    // 自動啟動 phantomjs
    use PhantomJSRunner;

    public function testSearchWithKeyword()
    {
        $driver = new Selenium2Driver('phantomjs');

        $session = new Session($driver);
        $session->start();

        $context = new Context($session, [
            'baseUrl' => 'https://www.google.com',
        ]);

        $context->createPage(Home::class)
            ->open()
            ->search('Jace Ju')
            ->shouldContainText('網站製作學習誌');
    }
}

這麼一來，在測試案例中就可以清楚地用頁面物件的行為去描述實際的需求，而不是落在操作 UI 的思維裡。讓外部的測試案例可以用更語意化的方式來使用這個類別，是一種 Tell Don't Ask 的實現。

總結

雖然舊專案可能難以做到單元測試，但我們可以先利用 Web 測試來驗證它已經存在的行為；而在 Web 測試中可以透過程式來控制瀏覽器，達到自動化測試的目的。在撰寫測試案例時，最重要的是對需求的描述，而不是 UI 操作的細節；因此可以用 Page Objects 模式來封裝 UI 細節，讓頁面物件提供有語意化的行為操作方式。

希望這個介紹能幫助大家對 Web 測試有基本的瞭解，當然在實務上可能會遇到的問題會更複雜；有機會的話我會另文分享自己在實務上遇到的問題，也歡迎大家提供不同的見解。

只是當我提出測試不該有邏輯時，討論就往該不該有 assertion library 偏過去了。我發現我太執著在這個點上，沒有正確地自己的想法傳達清楚。

所以接下來我會從幾個層面來討論測試該怎寫，將我想表達的觀念重新整理一下。

為什麼這樣寫測試有問題

起因就是原文的這個範例，這是它的待測目標：

<?php
$arg1 = $_GET['arg1'];
$arg2 = $_GET['arg2'];
$return = (int)$arg1 + (int)$arg2;
echo $return;

測試程式是這樣寫的：

<?php
// 把整個模擬測試流程寫成一個function，方便重用
function execute($arg1, $arg2){
    $_GET['arg1'] = $arg1;
    $_GET['arg2'] = $arg2;
    ob_start();
    include 'simple_add.php';
    return ob_get_clean();
}

$result = execute(1, 1);

if($result==2){
    echo "simple_add_test passed\n";
}else{
    echo "simple_add_test failed\n";
}

$result = execute(1, 2);

if($result==3){
    echo "simple_add_test passed\n";
}else{
    echo "simple_add_test failed\n";
}

$result = execute(1, -1);

if($result==0){
    echo "simple_add_test passed\n";
}else{
    echo "simple_add_test failed\n";
}

$result = execute(0, -1);

if($result==-1){
    echo "simple_add_test passed\n";
}else{
    echo "simple_add_test failed\n";
}
// 注意：後面的一大串if/else以及echo敘述，其實可以再包成function來簡化

如果這篇文章會繼續提到更嚴謹的做法，也許就不會有後續的討論了。事實上以往我在教測試時，也差不多是這樣開始的。只是整篇讀完後，我發現其實沒有任何後續 (雖然後來作者有提到會再寫) ，這才讓我開始擔心起來。

原本我想提的主要有兩點：

1. 這只是測試的初步觀念，但不是嚴謹的作法，更不是一種創意。

   當然在原文的範例裡，用 if == 來驗證其實是沒有問題的；只是當你信任這個驗證方式，測試也通過了，天下就太平了嗎？如同作者自己提到的，我們有機會在自己寫的 assertion 中犯錯；而當你發現錯誤其實是在自己的驗證程式時，我想後續的除錯成本就不在話下了。這也是為什麼我一直強調就算是要用自己的驗證機制，也應該對它進行驗證。

   至於測試中的 assertion 寫錯，跟該不該用第三方 assertion library 其實是兩回事，這點後面我會說為什麼。

2. 測試案例不該寫在一起，這樣會讓初學者覺得寫測試反而導致更多問題。

   再次強調，這個範例沒有問題不表示可以用這個做法通吃所有的狀況。測試案例彼此應該是獨立的，也就是我們要讓每個測試案例在執行時都不受到前一個測試案例的影響，讓我們能單純驗證目標對象的邏輯在受控環境的結果。

   一個好的測試案例應該只測一件事，而一件事通常是只會測試目標邏輯一次。如果今天 execute() 的邏輯中會有可能影響下一次執行結果的狀況，那麼這樣的寫法就有可能發生連續的錯誤，而你就很難確定錯誤是在哪個測試案例中開始的。

測試裡不該有邏輯

有朋友說，所以這些驗證工具裡面也是有 if 及 throw exception 的邏輯呀！怎麼會說測試裡不該有邏輯？

這裡確實是我表達得不夠好的點，也是討論上我過於執著的地方。事實上在 assertion 中的這些邏輯，是被封裝起來的，對我們來說就是不需要在意的邏輯，我們只要知道它是具有可靠性的黑盒子即可。所以最前面原文的那個例子，在 assertion 沒有被封裝的狀況下， if 嚴格來說就必須算是測試案例裡的邏輯。

我瞭解這解釋有點過於嚴格了，但其實我有強力阻擋的理由：當初學者認為這裡可以用 if 來判斷時，通常就會毫無限制地使用了。這也就為什麼我們常說：雖然你可以這麼做，但你不該這麼做。

還是要再次強調，因為範例中的判斷邏輯只是簡單的 == ，所以看不出會有什麼影響；但這只是為了說明測試的原理，不代表實務上可以這麼做。

只是到底什麼是測試裡的邏輯？舉例來說 try...catch 就不該出現在測試案例裡，接收異常的機制應該是由測試框架來處理，我們要確保的是待測試邏輯「一定會拋出預期的異常」，而 try...catch 就有不確定的意味存在。

測試的目的就是確保該發生的一定要發生，而不是去判斷某件事會不會發生。如果測試案例中包含了不確定性的邏輯，那就不叫測試了。

測試只是輔助

有朋友提到 TDD 循環，其實我認為是在這個討論中有些失焦了。但不是說提出 TDD 是不對的，事實上我非常認同；只是我在這裡想討論的是「測試的寫法」，換句話說，就是在紅燈之前你怎麼寫測試案例。

TDD 有一個很重要的觀念：確保我們想清楚規格了才去動手。

我們寫測試通常是為了有測試而寫，只是想要驗證到底我們寫出來的程式碼對不對。但真正好的測試案例應該是以測試程式來描述規格。

回頭看一下原文範例的寫法：

$result = execute(1, 1);

if($result==2){
    echo "simple_add_test passed\n";
}else{
    echo "simple_add_test failed\n";
}

當看到這個測試案例時，你知道原來的邏輯是做什麼的嗎？我想除了程式原作者之外，應該是沒人知道待測邏輯要做什麼吧？

「一個測試案例應該清楚描述待測對象的用途」，我們可以把測試案例想像成是 production code 的說明書，讓看到測試案例的人一眼就能明白該怎麼去使用待測對象。

之所以 assertion library 會封裝驗證的邏輯，除了提供可靠性之外，另一個目的就是提供較為語意化的 API 。例如 PHPUnit 的 assertEquals 、 assertContains 等，這些語義化的 API 很清楚地告訴我們要驗證的是什麼；如果用錯了，很有可能就是我們其實對需求理解得不夠明確。

那麼測試怎麼去描述需求呢？像是 JavaScript 的 mocha 框架就可以讓我們這樣寫：

describe('Array', function() {
  describe('#indexOf()', function() {
    it('should return -1 when the value is not present', function() {
      [1,2,3].indexOf(5).should.equal(-1);
      [1,2,3].indexOf(0).should.equal(-1);
    });
  });
});

像這樣就能清楚地表達陣列的 indexOf 方法可以怎麼用。你可以發現裡面其實沒有邏輯，因為「需求的 what 是不會有邏輯的，只有 how 才有邏輯。」

如果是原來的例子，如果萬不得已真的要自己寫驗證工具，可以寫成：

<?php // my_test_tools.php

function runScriptWithQuery($script, $queryParams = [])
{
    $_GET = $queryParams;
    ob_start();
    require $script;
    return ob_get_clean();
}

function assertEquals($expected, $actual)
{
    if ($expected == $actual) {
        echo "Passed\n";
    } else {
        echo "Failed asserting that $actual matches expected $expected.\n";
    }
}

用法會是這樣：

<?php // simple_add_test_cases.php
require 'my_test_tools.php';

function it_should_passed_with_1_add_2_equals_3()
{
    // Arrange
    $queryParams = ['arg1' => 1, 'arg2' => 2];
    $expected = 3;

    // Act
    $actual = runScriptWithQuery('simple_add_test.php', $queryParams);

    // Assert
    assertEquals($expected, $actual);
}

it_should_passed_with_1_add_2_equals_3();

註：避免跟原來的 simple_add_test.php 混淆，測試程式我改名為 simple_add_test_cases.php 。

這樣就可以很清楚的知道我們要測試的是 simple_add_test.php ，它的用途也是一清二楚。對看測試程式的人來說，它就是一種「對需求的描述」而不是「對程式邏輯的測試」。

該不該用自動化測試框架

在討論中 Ricky 提到沒有 PHPUnit 是不是就不能做測試了？這樣在沒有 PHPUnit 之前的程式碼不就不合格了？當然不是，還是強調一點：用自己寫的驗證機制是沒問題的，只要你能確保它驗證出來的結果是可信任的。

例如 c9s 提到 PHP 原始碼裡的一支測試：

--TEST--
Simple If/Else Test
--FILE--
<?php
$a=1;
if($a==0) {
    echo "bad";
} else {
    echo "good";
}
?>
--EXPECT--
good

事實上就是用到了 PHP 自帶的測試程式 (run-tests.php) ，因為在測試 PHP 語法這個需求當初並沒有適合的自動化測試框架，所以 PHP 需要自己建立一個。

註：要注意這個測試的對象是 if..else 這個語法，並不是指 if..else 就是用來做驗證的機制。

那為什麼我們還是需要 PHPUnit 或其他自動化測試框架？除了公認的可靠性之外，主要是它提供了我們在測試上很多重要的機制：

1. 自動化驗證：你可以專注在寫測試，該批次執行的事情框架都會幫你處理好。
2. 隔離測試：模擬待測試邏輯中被隔離出去的相依物件。
3. 程式碼測試涵蓋率：確保測試有測到待測邏輯。
4. 與其他開發工具的整合：例如 IDE 、 CI Service 等，以造就完整的開發生態圈。

這些都是真正實務上經過千錘百鍊後的特色，也適用在絕大多數的 PHP 專案上。如果專案沒有特別的需求，當然是優先使用別人寫好自動化測試框架。

結論

我一直很強調測試的重要性，但並不是要讓它變成我們開發上的負擔，而是用來輔助我們很快地去驗證我們的程式碼是否符合了需求。也就是說我們不要為了只是要驗證程式的正確性而去寫測試，而是應該讓測試來協助我們去理解程式想要滿足什麼需求。

工具是手段沒錯，但它的目的就是要幫我們很快地去把一件事做好。今天如果自己寫的工具可以做到這件事，那當然是很好的。但如果已經有更好的工具，為什麼不直接使用呢？當然工具會出錯，但 open source 的好處就是讓我們有機會去修補它們。當工具的公正性已經接受過時間的考驗以及許多案例的檢驗，我想那都會比你花時間自己弄一套來得嚴謹很多。

當然每個人心中對測試有自己的定見，我很難說服每一個人。但還是希望讓大家可以重新思考一下測試的本質，在正確的地方轉彎。

開始重構

當然重構前，我們必須先有測試做保障。在每個步驟完成後，我們都應該確保修改後的程式碼能通過測試的驗證。

接下來開始重構，這是原本的程式碼：

// Step 0
if ($errorRedirectViewType == 'create') {
    return Redirect::route(self::__module . '.' . self::__function . '.' . $errorRedirectViewType)
        ->with('message', '一樣的 message')
        ->withInput($allInput);
} else {
    return Redirect::route(self::__module . '.' . self::__function . '.' . $errorRedirectViewType, ['id' => $allInput['id']])
        ->with('message', '一樣的 message')
        ->withInput($allInput);
}

第一步我們引入一個 $redirect 變數：

// Step 1
$redirect = null;
if ($errorRedirectViewType == 'create') {
    $redirect = Redirect::route(self::__module . '.' . self::__function . '.' . $errorRedirectViewType)
        ->with('message', '一樣的 message')
        ->withInput($allInput);
} else {
    $redirect = Redirect::route(self::__module . '.' . self::__function . '.' . $errorRedirectViewType, ['id' => $allInput['id']])
        ->with('message', '一樣的 message')
        ->withInput($allInput);
}
return $redirect;

第二步我們把共用的部份移出 if...else 外：

// Step 2
$redirect = null;
if ($errorRedirectViewType == 'create') {
    $redirect = Redirect::route(self::__module . '.' . self::__function . '.' . $errorRedirectViewType);
} else {
    $redirect = Redirect::route(self::__module . '.' . self::__function . '.' . $errorRedirectViewType, ['id' => $allInput['id']]);
}
return $redirect
        ->with('message', '一樣的 message')
        ->withInput($allInput);

第三步把 if...else 提煉成 redirectByViewType 方法：

// Step 3
// Extracted method
protected function redirectByViewType($errorRedirectViewType, $id)
{
    $redirect = null;
    if ($errorRedirectViewType == 'create') {
        $redirect = Redirect::route(self::__module . '.' . self::__function . '.' . $errorRedirectViewType);
    } else {
        $redirect = Redirect::route(self::__module . '.' . self::__function . '.' . $errorRedirectViewType, ['id' => $id]);
    }
    return $redirect;
}

然後改用新的 redirectByViewType 方法：

// Step 3
$redirect = $this->redirectByViewType($errorRedirectViewType, $allInput['id']);

return $redirect
        ->with('message', '一樣的 message')
        ->withInput($allInput);

至於第二步到第三步要不要做，就看我們有沒有 reuse 這段邏輯的需求；但一般我會做，因為程式碼看起來好讀，後面也可以再做其他重構。

第四步就可以把原來的 $redirect 拿掉，因為不需要了。

// Step 4
return $this->redirectByViewType($errorRedirectViewType, $allInput['id'])
        ->with('message', '一樣的 message')
        ->withInput($allInput);

這種先引入一個臨時變數讓重構好進行的方式，是很常見的。而什麼時候應該需要使用這個技巧？這就要多累積經驗。通常你可以想像一下重構後的程式碼，大致與重構前會有什麼樣的差異，再判斷是否需要引用一個臨時變數。

第五步，我們把 redirectByViewType 重複的程式碼再引用一個解釋用的變數 $routeName ：

// Step 5
protected function redirectByViewType($errorRedirectViewType, $id)
{
    $redirect = null;
    $routeName = self::__module . '.' .
               self::__function . '.' .
               $errorRedirectViewType;

    if ($errorRedirectViewType == 'create') {
        $redirect = Redirect::route($routeName);
    } else {
        $redirect = Redirect::route($routeName, ['id' => $id]);
    }
    return $redirect;
}

這樣程式碼就更容易被理解了。

後記

希望這個小例子可以讓大家瞭解到，實戰中的重構其實是很簡單的。它就是在不更改原有邏輯的狀態下，一步一步讓你的程式碼變得更易讀也更易維護。

當初因為是臨時示範給學員看，所以並沒有特別加上測試，也沒有用 PhpStorm 來協助重構；結果後來我發現在 extract method 時，忘了把 $allInput['id'] 帶到 redirectByViewType 裡面。

這就是一種工程師很容易忽略的盲點，就是太容易相信自己的想法，而不是真正去驗證它。在沒有測試和工具的輔助下，千萬要特別小心這種小錯誤。

註：類似的工類還有用 Go 寫的 MailHog ，據說速度更快；雖然我還沒試過，但我想用法應該是相同的。

以下就簡單介紹一下如何在 Laravel 5.1 上使用 MailCatcher 。

安裝 MailCatcher

這裡我們用 Homestead 示範，先把 Homestead 的 port 1080/1025 導到本機的 port 1080/1025 ，方便稍後在本機操作。執行：

$ homestead edit

註： $ 為提示字元，不需要輸入。

然後加入：

ports:
    - send: 1080
      to: 1080
    - send: 1025
      to: 1025

接著進入 Homestead ：

$ homestead up
$ homestead ssh

確認 Ruby 環境是安裝好的：

$ ruby -v
ruby 2.1.2p95 (2014-05-08) [x86_64-linux-gnu]

$ gem -v
2.2.2

然後安裝 MailCatcher ：

$ sudo gem install mailcatcher --no-ri --no-rdoc

安裝完成後，直接執行 mailcatcher ：

$ mailcatcher --ip 0.0.0.0
Starting MailCatcher
==> smtp://0.0.0.0:1025
==> http://0.0.0.0:1080
*** MailCatcher runs as a daemon by default. Go to the web interface to quit.

這樣 MailCatcher 的 port 1025 就會監聽 SMTP 請求，而 port 1080 就會是它的 Web 管理介面。

打開本機的瀏覽器，瀏覽 http://127.0.0.1:1080 ，應該就會看到 MailCatcher 的 Web 管理介面：

修改 Laravel Mail 設定

這裡我假設你已經建立一個 Laravel 5.1 專案了，所以修改 .env 中的 MAIL_HOST 與 MAIL_PORT 即可：

MAIL_HOST=127.0.0.1
MAIL_PORT=1025

其他一切都可以不需要改動。

測試發送信件

我們可以直接用 tinker 來測試是否能夠發送信件，執行：

$ php artisan tinker
Psy Shell v0.5.2 (PHP 5.6.8 — cli) by Justin Hileman
>>>

然後輸入：

Mail::raw('This is a test mail', function ($message) {
$message->subject('Test');
$message->from('laravel@example.com', 'Laravel');
$message->to('user@example.com');
});

結果應該會回傳 1 ，然後你可以回到瀏覽器查看 MailCatcher 是否有收到這封信，結果應該會如下圖所示：

與其他測試框架的整合

MailCatcher 可以跟 PHP 的自動化測試框架做很好的整合，詳情可以參考以下文章：

• PHPUnit - Testing Emails in PHP. Part 1: PHPUnit
• Behat - MailCatcher extension for Behat
• Codeception - Test emails in your Codeception acceptance tests

教學影片中雖然是使用 Pusher 服務來做事件推送，不過 Laravel 也可以搭配 Redis 來做到同樣的事情。考量到未來的系統發展，我打算採用 Redis 來當做事件推送伺服器，所以本文也會在此基礎進行說明。

以下就來介紹如何用 Laravel 的 Events Broadcasting 來實作一個簡單的聊天室。

原理

簡單說明一下本文的實作原理：

1. 啟動 Redis 伺服器來監聽 Laravel 發送出來的事件。
2. 透過 Node Express 建立一個 Socket.IO Server ，並且接收 Redis Server 推送過來的事件，然後將它廣播到 WebSocket 上。
3. 瀏覽器上建立與 Socket.IO Server 的連結，透過 WebSocket 接收事件來完成即時互動。

開發環境

Laravel 官方推薦開發者使用 Homestead ，原因是它已經幫我們安裝好所有 Laravel 需要的執行環境，例如 Redis 與 Node.js 。在繼續下去之前，請先依照官方說明 (中文版) 將 Homestead 安裝好。

然後利用 homestead edit 打開 Homestead 的設定檔：

註：以下指令中，開頭的 $ 為系統提示符號，不用輸入。

$ homestead edit

確認本機路徑 ~/Projects 有正確 mount 到 Homestead 的 /home/vagrant/Projects 上。

folders:
    - map: ~/Projects
      to: /home/vagrant/Projects

要連上 Homestead 裡的虛擬站台 (Virtual Host) ，必須要讓本機認得專案對應的 hostname 。所以要編輯本機的 /etc/hosts ，加入 IP 與 hostname 的對應：

192.168.10.10 chat-room.app

192.168.10.10 是在 Homestead.yml 中設定的 IP 。

啟動 Homestead ，並用 ssh 連入 Homestead ：

$ homestead up
$ homestead ssh

檢查 node.js 版本：

$ node -v
v1.8.1

註： Homestead 是透過 nvm 安裝 io.js ，所以可以自行升級 io.js 到最新版。

檢查 redis 是否啟動：

$ redis-cli ping
PONG

新增一個虛擬站台：

$ serve chat-room.app ~/Projects/chat-room/public

建立應用程式

在 Homestead 中，利用 composer 來下載已經設定好的 Laravel 5.1 Boilerplate ，執行：

$ cd ~/Projects
$ composer create-project jaceju/b5 chat-room -s dev

程式就會開始下載並進行安裝。完成後進入專案資料夾，以便進行後續操作。

$ cd chat-room

調整 gulpfile.js

在 Homestead 上開發時，不需要啟動 Web Server ，因此要調整 gulpfile.js 。

編輯 gulpfile.js ，把 port 變數與 serve task 移除，並將 proxy 改到 chat-room.app ，完成後如下：

// ... (略)

elixir(function (mix) {
    mix.clean()
        .sass('*.scss')
        .wiredep()
        .jshint()
        .sync('resources/assets/js/**/*.js', 'public/js');

    if (elixir.config.production) {
        mix.useref({ src: false })
            .version(['js/*.js', 'css/*.css'])
    }
});

安裝必要套件

Laravel 操作 Redis 是透過 Predis 套件，所以我們要透過 composer 安裝：

$ composer require predis/predis

接下來要透過 Npm 與 Bower 安裝 Socket.IO Server 相關套件，包含前後端：

$ npm install express ioredis socket.io --save
$ bower install socket.io-client --save

建立 Socket.IO Server

接下來要利用 Node.js 的 express 和 http 模組建立一個 Web Server ，然後讓 Socket.IO 透過這個 WebServer 來廣播從 Redis 接收到的事件。先建立 socket.js ，內容為：

var app = require('express')();
var http = require('http').Server(app);
var io = require('socket.io')(http);
var Redis = require('ioredis');
var redis = new Redis();

// Redis 訂閱 `chat-channel` 頻道
redis.subscribe('chat-channel', function (err, count) {
});

// 當 Redis 有事件發生時，透過 Socket.IO Server 發送事件
redis.on('message', function (channel, message) {
    message = JSON.parse(message);
    io.emit(channel + ':' + message.event, message.data);
});

// 讓用戶端可以透過 Port 3000 連接 Socket.IO Server
http.listen(3000, function () {
    console.log('Listening on Port 3000');
});

然後在 Homestead 上啟動 Socket.IO Server ：

$ node socket.js &
Listening on Port 3000

修改設定

Laravel 5.1 預設是使用 Pusher 做為事件推送伺服器，可以在 config/broadcasting.php 裡看到這個設定：

'default' => env('BROADCAST_DRIVER', 'pusher'),

因為這裡使用了 env 函式，所以我們可以編輯 .env ，加入以下設定來改用 Redis 伺服器：

BROADCAST_DRIVER=redis

建立 Event 類別

接下來就要讓 Laravel 能夠發送事件了，在 Laravel 5.0 以後的版本提供了 make:event 這個指令可以協助我們建立 Event 類別。首先我們的聊天室需要一個「訊息被建立」的事件，所以執行：

$ php artisan make:event MessageCreated

這樣就會建立 app/Events/MessageCreated.php 。

接著我們要讓 MessageCreated 類別能夠被 Redis 推送，所以編輯 app/Events/MessageCreated.php ，讓它實作 Illuminate\Contracts\Broadcasting\ShouldBroadcast 介面。

use Illuminate\Contracts\Broadcasting\ShouldBroadcast;

class MessageCreated extends Event implements ShouldBroadcast

在推送事件時，我們可以附帶一組要傳送的資料，稱為 payload 。通常我們會在 Event 類別的建構子中帶入 payload 。修改 MessageCreated 類別，加入 $username 與 $message 屬性，並在建構子中注入：

private $username;

private $message;

public function __construct($username, $message)
{
    $this->username = $username;
    $this->message = $message;
}

接著我們要讓它能在推送事件時，把這兩個屬性一起傳送出去；主要是透過 broadcastWith 這個方法：

public function broadcastWith()
{
    return [
        'username' => $this->username,
        'message' => $this->message,
    ];
}

最後我們需要一個頻道來廣播事件，這是因為要讓 Redis 可以識別要廣播的對象。我們可以在 broadcastOn 方法回傳 Redis 訂閱的頻道名稱，即為前面指定的 chat-channel ：

public function broadcastOn()
{
    return ['chat-channel'];
}

註：一個事件可以廣播給數個頻道，所以這裡要回傳一個陣列。

完成後的程式碼如下：

<?php

namespace App\Events;

use Illuminate\Contracts\Broadcasting\ShouldBroadcast;
use Illuminate\Queue\SerializesModels;

class MessageCreated extends Event implements ShouldBroadcast
{
    use SerializesModels;

    private $username;

    private $message;

    public function __construct($username, $message)
    {
        $this->username = $username;
        $this->message = $message;
    }

    public function broadcastWith()
    {
        return [
            'username' => $this->username,
            'message' => $this->message,
        ];
    }

    public function broadcastOn()
    {
        return ['chat-channel'];
    }
}

建立 Routes 與 Controller

這裡我們只需要兩個 route ：聊天室頁面，以及發送訊息。改寫 app/Http/routes.php ，內容如下：

<?php
get('/', 'ChatController@index'); // 聊天室頁面
post('send-message', 'ChatController@sendMessage'); // 發送訊息

然後要建立 ChatController 來處理程式流程，在 Terminal 中執行：

$ php artisan make:controller ChatController --plain

編輯新建立的 app/Http/Controllers/ChatController.php ，先加入 index 方法：

public function index()
{
    srand(time()); // 亂數種子
    $username = sprintf('user%06d', rand(1, 100000)); // 決定 user 名稱 (註)
    return view('chat', compact('username'));
}

在 index 方法中，主要是產生一個隨機的使用者名稱，並顯示在首頁樣版裡。

註：這裡產生 username 的方法並不嚴謹，沒有考慮到名稱重複的問題，但現階段先暫時這樣。

接下來我們要接收使用者建立的訊息，然後發送一個「訊息被建立」的事件，所以新增 sendMessage 方法，內容為：

public function sendMessage(Request $request)
{
    $username = $request->get('username');
    $message = $request->get('message');
    event(new MessageCreated($username, $message));
    return 'message sent';
}

建立樣版頁面

切換到前端開發模式，我們要修改一下介面的呈現。

先處理 HTML 的部份，將原來的 resources/views/welcome.blade.php 重新命名為 resources/views/chat.blade.php ，將 div.container 的內容修改如下：

<div class="container">
    <div class="row">
        <div class="col-md-6 col-md-offset-3">
            <h1>Chat Room Demo</h1>

            <!-- 訊息列表框 -->
            <div id="chat-room">

            </div>

            <!-- 輸入訊息的表單 -->
            <form id="send-message" method="post" action="/send-message">
                {!! csrf_field() !!}
                <input type="hidden" name="username" value="{{ $username }}" />
                <div class="input-group">
                    <label class="input-group-addon">{{ $username }}</label>
                    <input id="message" type="text" value="" class="form-control" />
                    <span class="input-group-btn">
                        <button class="btn btn-success" id="send">Send</button>
                    </span>
                </div>
            </form>
        </div>
    </div>
</div>

這樣會讓畫面上有一個訊息列表框以及一個輸入訊息的表單，如下圖所示。

接下來稍微調整介面的樣式，編輯 resources/assets/sass/app.scss ，將內容修改如下：

@import "../../../public/bower_components/bootstrap-sass/assets/stylesheets/bootstrap";

html, body {
  height: 100%;
}

// 訊息列表框
#chat-room {
  border: 1px solid #ccc;
  height: 20rem;
  padding: 1rem;
  overflow-x: hidden;
  overflow-y: auto;

  // 單則訊息
  .message {
    padding: 1rem;
    margin-bottom: 1rem;
  }
}

// 輸入訊息的表單
#send-message {
  margin-top: -1px;

  .input-group-addon {
    border-top-left-radius: 0;
  }

  .input-group-btn > .btn {
    border-top-right-radius: 0;
  }
}

最後透過 JavaScript 讓所有東西串在一起，

編輯 resources/assets/js/app.js ，內容如下：

'use strict';
var $chatRoom = $('#chat-room');
var $sendMessage = $('#send-message');
var $messageInput = $sendMessage.find('input[name=message]');
var io = window.io;
var socket = io('http://chat-room.app:3000');

// 當送出表單時，改用 Ajax 傳送，並清空輸入框。
$sendMessage.on('submit', function () {
    $.post(this.action, $sendMessage.serialize());
    $messageInput.val('');
    return false;
});

// 當接收到訊息建立的事件時，將接收到的 payload
socket.on('chat-channel:App\\Events\\MessageCreated', function (payload) {

    var html = '<div class="message alert-info" style="display: none;">';
    html += payload.username + ': ';
    html += payload.message;
    html += '</div>';

    var $message = $(html);
    $chatRoom.append($message);
    $message.fadeIn('fast');
    $chatRoom.animate({scrollTop: $chatRoom[0].scrollHeight}, 1000);
});

執行測試

在 Homestead 上執行：

$ gulp

然後在本機分別開啟兩個瀏覽器視窗瀏覽 http://chat-room.app ，然後在輸出框上輸入文字後按 Send ，應該就會讓兩個瀏覽器同時出現相同的文字。

完成的範例可以在我的 GitHub 上找到。

結論

這個 Demo 如果真的要在實務上使用，還有很多地方要考慮，例如訊息歷史、使用者登入等等。不過這已經足夠讓我們瞭解 Laravel 5.1 在實作 Broadcasting 時有多麼輕鬆，使得我們更容易在專案前期就先實現很多想法。

希望這個簡單的教學，能對大家使用 Laravel 來開發即時系統時有所幫助。

參考

• Step by Step Guide to Installing Socket.io and Broadcasting Events with Laravel 5.1

這裡我對前端框架的定義是包含了頁面排版、風格樣式、 UI 元件等，不限純 CSS ，可以包含 JavaScript 。

本文從以前我所使用及目前研究的幾個前端框架，依照研究的深入程度，由深至淺來簡單分享我個人的一些分析心得。至於優缺點，完全是個人主觀意見，大家參考看看即可。

Twitter Bootstrap

Twitter 所推出的 Bootstrap 大概是使用者最多，資源也最豐富的框架了。因為推出時間較早， Bootstrap 的社群也相當龐大；不少開發者也在它的基礎上建立了很多自訂的元件，延續了它在前端的戰場生命。

一開始 Boostrap 是以 LESS 開發的，不過後來官方也提供了 SASS 版本；對我來說，在開發流程裡就不會再有 LESS 和 SASS 混搭的問題了。

優點

Boostrap 包含的樣式與元件都已經涵蓋了多數應用場合，而且文件非常完整。有許多第三方 UI 元件都是基於它來開發的。另外也有很多開發者在 Boostrap 的基礎上建立出多種 Theme 讓開發者套用，讓 Bootstrap 能跟上目前時下流行的網站設計風格。

在 Boostrap 的 LESS 與 SASS 版本中，都提供了大量的變數讓使用者可以做出自己的 Boostrap 客製化版本；而 Boostrap 也提供了線上客製功能，讓官方網站直接幫你組合出適合你的 Boostrap 。

缺點

就我個人的使用經驗來看，稍微複雜的 Grid 系統常常需要多層巢狀 HTML 標籤來組合，大概就是 Bootstrap 的罩門了。另外表單的排版也是不夠簡明，一個小 UI 可能需要好幾層 HTML 來組合。

相依在 jQuery 上或許是另一個小缺點，兩者的 JavaScript 檔案大小相加後超過 100KB ，在行動裝置上使用時要特別注意載入的效率。

相關資源

• Bootsnipp - 讓使用者分享他們的 Bootstrap 元件或頁面範例。
• Bootswatch - 提供多種 Theme 讓使用者套用。
• Built with Bootstrap - 收集許多用 Boostrap 製作的網站。
• Pingendo - 使用 Bootstrap 來做 prototype 的 Mac App 。
• GitHub 上的相關專案

Semantic UI

一套強調語意化的前端框架，主要是在 HTML 標籤的 class 屬性去組合語意。例如兩欄等高的排版會長這樣：

<main class="ui two column equal height page grid">
    <div class="stretched divided row">
        <section class="twelve wide column"> ... </section>
        <aside class="four wide column"> ... </aside>
    </div>
</main>

從 class 就可以看到跟 Boostrap 非常不一樣的設計理念，像 column 在不同的位置會有不一樣的解釋。第一層的 two column ... page grid 指這個 grid 裡會包含兩欄，而後的 twelve wide column 與 four wide column 則定義了欄的寬度。

另外 Semantic UI 2.0 有個特別之處，就是它在 Layout 和 UI 元件上，全部採用了 CSS Flexbox 設計。當然這樣會有瀏覽器支援的問題，但如果不必考慮這個問題的話，這樣的設計實在是讓我覺得很舒服。

目前 Semantic UI 是採用 LESS 開發，還沒有官方的 SASS 版本。

優點

Semantic UI 透過 class 的語意化組合使得頁面的 HTML 變得很簡潔，讓開發者不會像 Bootstrap 一樣迷失在 HTML 標籤海裡。另外搭配 HTML5 本身的語意化標籤，讓開發者可以更輕鬆地定位到他想套用程式的位置。

另一個優點是它的 UI 預設風格非常精緻，個人還滿喜歡的。當然它也跟 Boostrap 一樣可以更換 Theme ，而且在設計上是採用三層繼承架構。

缺點

雖然說語意化排版是 Semantic UI 的強項，但卻讓人有不知道該怎麼組合的挫敗感；網路上有關 Semantic UI 的 Layout 範例都停留在舊版，著實讓我在用 2.0 版時頭痛了一陣子。所幸最近官方的文件正逐漸改進中，應該能解決掉這個問題。

另外社群針對 Semantic UI 所寫的第三方 UI 元件實在不多，內建的元件也不如 Boostrap 多樣化；如果你不打算自己開發 UI 元件的話，這相當於限制你只能在這個框架中尋找替代做法。

Semantic UI 在 Responsive 的部份也必須因為有不同的排版策略而有不同的 HTML 區塊，這點反而不如 Boostrap 的設計 (但搭配 RESS 後反而變成優點了) 。

相關資源

• Learn Semantic

UIKit

UIKit 是 YOOTheme 開發的一套前端框架，除了 class 名稱不太一樣之外，整體設計理念很接近 Boostrap 3 ；尤其是 Responsive Grid 的設計，跟 Boostrap 如出一轍。

UIKit 的所有元件都做了 Responsive 化，同時把所有資訊都寫在 HTML 標籤上，所以它的元件不需要像 Boostrap 一樣寫額外的 JavaScript ；只要在元件 HTML 標籤上定義相關屬性，接下來的事情會由 UIKit 的 JavaScript 程式庫處理掉。不過它和 Boostrap 一樣，也需要 jQuery 的支援。

目前 UIKit 是採用 LESS 開發，還沒有官方的 SASS 版本。

優點

UIKit 的官方文件相當齊全，完全不輸 Bootstrap ；部份常用的 Web 元件甚至是 Bootstrap 所沒有提供的，像是 Date Picker 與 HTML Editor ，讓開發者不需要引用太多第三方套件。

除了傳統 Grid 排版， UIKit 也提供了 Flex 排版機制；讓開發者在不需考慮瀏覽器支援度的狀況下，可以更靈活地安排版面。

缺點

也因為 UIKit 跟 Boostrap 很像，所以在排版上也有多層巢狀 HTML 標籤的問題，不過與 Bootstrap 相比，已經改善不少。

另外也許是因為 UIKit 非大公司出品，在社群上的討論度不那麼高，使得它在第三方的支援上就不如 Boostrap 這麼廣泛。不過我想 UIKit 本身所提供的這些元件，就應該足以應付常見的需求了。

相關資源

• UIKit 中文網

Materialize

Materialize 是一群 Carnegie Mellon University 的學生，依照 Google 的 Material Design 所開發出來的框架。從它的 Grid 範例來看，應該也參考不少 Bootstrap 的設計。

目前 Materialize 是採用 SASS 開發，還沒有官方的 LESS 版本。

優點

Materialize 是目前實作較完整的 Material Design 框架，大多數 Material Design 的模式都很容易在這個框架中實現。而除了 class 名稱不同外，大多數的元件在使用上和 Bootstrap 是差不多的。它的文件非常清楚簡潔，大多數元件只要看範例就知道如何使用了。

如果你非常想在新專案實現 Material Design ，那麼這個框架絕對是首選。而如果你熟悉的是 Bootstrap ，但又想套用 Material Design 的話，可以參考看看 Bootstrap Material Design 。

缺點

因為 Materialize 發展還不到一年，所以社群支援程度還不夠高，相關應用發展也是不如 Bootstrap ；不過我想這個問題會因為 Material Design 被高度關注的狀況下，逐漸得到解決。

相關資源

• 5 Material Design Examples using MaterializeCSS
• Material Design Blog

Material Design Lite

Material Design Lite 是 Google 自己推出的 Material Design 框架，它的出現造成了社群中高度的討論。我個人是認為 Google 推出 Material Design Lite 其實帶有宣示的意味，它要讓開發者知道 Google 對 Material Design 真正想表達的就實現在這裡了 (當然這是我自己猜想的，沒有什麼根據) 。

目前 Material Design Lite 是採用 SASS 開發，還沒有官方的 LESS 版本。

優點

Material Design Lite 是 Google 推出的，未來發展性也許不錯 (雖然有可能夭折) 。

缺點

因為 Material Design Lite 的 class 是採用 BEM ，所以就有了 class 爆炸的問題，一個元件的定義可能就會包含了十來個 class 。

另外因為剛推出不久，它的元件也不夠豐富，文件的流暢性也不像其他框架這麼好。總之這個框架還需要時間熟成，有興趣的朋友不妨耐心等候。

結論

好的前端框架如果用在正確的地方，絕對可以節省很多開發時間。當然如果你的設計不是那麼中規中矩時，套用這些框架反而容易綁手綁腳，比不用還糟糕。

官方也介紹了 5.1 有哪些新特色 ，以下我會簡單介紹它們。

不再支援 PHP 5.5.9 以前的版本

從推出以來，我個人認為 Laravel 的作者似乎都一直在依循著 PHP 的新特色來開發 Laravel ，讓整個 Framework 不論在程式架構或效能上，都能保持在一定的水準。這次 5.1 版也是如此，直接就告訴大家：該把 PHP 升級到 5.5.9 以上的版本了，這樣才能使用新版的 Laravel 所帶來的好處。

很難想像這樣先進的 PHP Framework 的開發作者，原來是寫 .Net 的；而在開發 Laravel 之前完全沒學過 PHP ，真是令我汗顏。

第一個 LTS 版本

當然隨著 PHP 持續演進的過程中，勢必就得有所取捨；這樣的特色讓許多依賴舊的 Laravel 版本所開發的專案，在穩定與升級之間面臨很大的抉擇。到了 Laravel 5.1 ，作者終於正式宣佈它是一個 LTS (Long Term Support) 版本，將會讓企業安心用它來開發需要穩定的長期專案。

也就是說現在用 Laravel 5.1 開發的專案，在未來的兩、三年內可以不用再怕沒人修核心的 bug 了。

新的文件

在 5.1 將要發佈之前，作者花了很多心力在完善文件。例如 Authentication 的部份就做了很完整的 Quickstart 範例，讓開發者瞭解如何去實作自己的認證機制。另外即時搜尋也是這次文件系統的新特色，讓開發者可以很快地用關鍵字來查閱相關說明。

不過我還是覺得字太小，而且每次要看其他章節都得捲回去頁首。

PSR-2

在 Laravel 5.1 之前的版本，讓我最困擾的就是作者自己弄了一套 Coding Style ，而不是照著 PSR 標準走。終於在眾開發者的要求下，作者從善如流，讓核心代碼以及產生器所產生的程式碼，都遵守了 PSR-2 標準。

這個結果，我只能拍手叫好了；因為即便 PSR-2 再怎麼不如己意，但它終歸是大家討論出來的標準。 (公司的 coding style 也不正是如此嗎？)

• 相關影片： Adopting PSR-2

在樣版中注入服務

在 Blade 引擎中也新增了一個 @inject 指令，讓開發者可以即時地注入一個物件。

@inject('metrics', 'App\Services\MetricsService')

<div>
    Monthly Revenue: {{ $metrics->monthlyRevenue() }}.
</div>

這樣一來應該就可以不必在 Controller 或 View Composer 中引入變數了。

• 相關文件： Blade Templates - Service Injection
• 相關影片： Injecting Services With Blade

Middleware 參數

原本我們只能從傳入 request 物件給 middleware ，再從 request 物件中取得參數給 middleware 使用；在新版本終於可以自訂 middleware 的參數，再從 route 的定義裡傳入參數給 middleware 。

例如在製作權限系統時，就可以在 route 傳入指定的角色，讓管理權限的 middleware 判斷使用者是否符合這個角色。

class RoleMiddleware
{
    public function handle($request, Closure $next, $role)
    {
        if (! $request->user()->hasRole($role)) {
            // Redirect...
        }

        return $next($request);
    }
}

Route::put('post/{id}', ['middleware' => 'role:editor', function ($id) {
    //
}]);

另外 Middleware 的設計也因為底層的 Symfony 採用了剛定案的 PSR-7 標準，所以也符合 PSR-7 的標準。

• 相關文件： HTTP Middleware - Middleware Parameters

事件廣播

Laravel 原本已經包含了一個強大的事件系統，現在加上實作更簡單的事件廣播功能，能讓開發者搭配特定的服務 (例如 Redis) 以廣播 WebSocket 事件，便可以更有效率地做出即時應用程式。

原本我打算用 ReactPHP 的說，看來又要改變主意了。

• 相關文件： Events - Broadcasting Events
• 相關影片： The Power of Eventing (需付費)

更完整的測試框架

先前的版本所提供的測試工具提供的功能有限，僅能做到部份的整合測試。現在 Laravel 5.1 引入了 laracasts 的測試套件，讓整合測試變得更易讀。

我才剛把 Codeception 引入而已，這套要不要用可能要再研究一下。

• 相關文件： Testing

小結

據作者說， Laravel 5.1 是他目前最滿意的版本；當然這或許有些老王賣瓜的感覺，但從 Laravel 3 追到現在，我也覺得 Laravel 真的是與時俱進，不斷地結合許多先進的開發觀念。

接下來我會把一些目前正在執行的專案都換成 5.1 ，再來看看它是不是真的有如作者所說的這麼強大。

現在我是用 Mac 來當做開發環境，所以簡單記錄一下如何在 OS X 上建立 Selenium 測試環境。

Selenium 的簡單原理與應用可以參考：自動測試與 TDD 實務開發 - 上課心得 (中)

準備工作

1. 確認可以執行 Java ，因為 Selenium Server 需要用 Java 執行；如果沒有 Java 的話，可以去 Oracle 官方網站下載 後安裝。
2. 確認可以執行 homebrew ，因為稍後有幾個套件會使用它來安裝。
3. 在適合的位置建立一個新資料夾，例如 ~/Selenium ，接下來的工作都會在這裡進行。
4. 最後在 Terminal 中下載我寫好的 script 並執行它，它會下載 selenium server 並安裝 ChromeDriver 及建立 Firefox Profile。

完整的指令如下：

mkdir -p ~/Selenium && cd $_
curl -S -s -L https://goo.gl/s519kT > run-selenium
chmod +x run-selenium && mv run-selenium /usr/local/bin
run-selenium init

設定瀏覽器

先確認好已經安裝 Firefox 、 Google Chrome 等瀏覽器， Safari 則已內建。

Google Chrome

ChromeDriver 可以讓 Selenium Server 呼叫 Google Chrome 執行；如果前面已經執行過 ./run-selenium init 的話，就已經安裝好了。可以在 Terminal 執行 chromedriver -v 來驗證是否正確安裝。

Safari

SafariDriver 則可以讓 Selenium Server 呼叫 Safari 執行，它是一個 Safari Extension ，必須手動安裝。

1. 在 Selenium 官網下載頁找到 SafariDriver ，下載 Latest release 連結的 SafariDriver.safariextz 檔。
2. 用滑鼠雙擊 SafariDriver.safariextz 檔， Safari 會提示是否安裝 WebDriver ，選「安裝」。
3. 開啟 Safari ，在「偏好設定」裡面切換到「延伸功能」頁籤。
4. 在「延伸功能」頁籤畫面上，應該就會有 WebDriver ，確認它有被啟用。
5. 最後在「安全性」頁籤畫面上，將「阻擋彈出式視窗」取消勾選，避免阻擋測試程式執行。

啟用並停用 Selenium Server

在要測試之前，啟用 Selenium Server ：

run-selenium start

要結束 Selenium Server 則是：

run-selenium stop

測試用範例

這邊已經有個我寫好的範例，它整合了以下幾個 Selenium Server 的用法：

• PHPUnit Selenium
• PHP WebDriver
• Codeception WebDriver Module

用法請參考 README 說明。

參考

• Automating Headless Selenium PHPUnit Tests
• Elemental Selenium - How To Use Safari

前兩週講師介紹了單元測試基礎以及如何重構舊有程式之後，但我們依舊面臨了一個很大的問題，那就是：「我們寫出來的程式，不見得就是我們所想的；而就算符合我們想的，也不見得是需求要的。」

「嘿！你沒睡好嗎？上星期提的搜尋功能你應該完成了吧？」
「嗯，我昨天加班完成了，還加上了測試，應該很完美，你試試。」

不久後...

「怎麼我搜尋『特價』這個字，沒有出現特價商品的類別頁？」
「不是吧？搜尋結果應該是獨立的搜尋列表呀！這不是 common sense 嗎？」
「不對不對，你應該在我搜尋『特價』的時候，直接導到特價商品頁就好了。」
「靠！這兩回事吧？而且你給的的需求只有搜尋商品而已，剩下的要我自己腦補喔？」

如果這種戲碼常常在辦公室上演的話，浪費的可不只是開發人員的時間呀！面對不清不楚的需求，或是雙方對需求的認知上有所誤解，甚至開發人員「善意地」加入根本不在需求裡的程式碼，這些問題都將可能拖垮整個專案的進度！

所以最後一週，講師為我們帶來了整套課程的高潮：不僅僅是以規格來完成程式碼，更能用規格來自動驗證你的程式碼！

測試驅動了開發，那什麼驅動了測試？

自從大師們對 TDD 進行一場論戰後，很多人發現自己誤解了 TDD 的真義，那就是：所謂的測試驅動從來不是為了「讓系統因為有寫測試而顯得專業」或是「儘可能寫出完美而獨立的測試程式」，而是「從有目標的測試中來完成程式碼」。

TDD 雖然能驅動著開發者專注在測試所在乎的目標上，讓程式碼不會有過度設計的問題；但當目標錯誤的話，即便測試寫得再完整也是白搭。然而測試的目標到底是什麼呢？想當然爾就是我們的需求規格；不過這兩者之間還是存在著巨大的門檻，所以我們要面對的問題是：到底要怎麼讓需求轉換成測試的目標？而且隨著需求不斷地成長，也要能驅動我們的測試持續演進？

需求該如何描述？

「網站這麼大，使用者很難一下子就找到他們要的商品，我們是不是應該有個搜尋商品的功能？」當客戶提出這樣的需求時，他們通常不明白也不需要明白程式是怎麼做的 (他們只知道這樣的描述可以讓工程師累垮) 。為了避免客戶與工程師之間有認知上的落差，專案負責人 (PO, Product Owner) 可能就會想辦法生出一大堆文件，來描述詳細的系統規格。

然而我們都知道在大環境的變化下，需求可能會被改得面目全非，先前寫好的文件已然成為一堆廢紙。為了不要大家做白工，敏捷開發提出了 User Stories 這個方式，讓真正有價值的需求能被先簡約地描述出來，而不是一開始就陷在文件地獄裡。

通常一個 User Story 可以用以下的格式來描述：

As a <role>, I want to <action> because of <business value>.
(「某個角色」可以「做某件事」來得到「有商業價值的結果」)

例如：

「使用者」可以「輸入關鍵字」來「找出站內的商品」

這樣就是一個 User Story ，它明白地指出需求的目標是什麼，而不會包含技術細節。基本上，我們可以把 User Story 想成是用來確認產品功能的大綱，實作細節可以在之後補上，就不會因為需求的變化而浪費大家的時間。更詳細的 User Story 介紹可以參考以下文章：

• User Stories (1) 什麼是 User Story? by ihower (結果這系列好像富奸了…)
• 撰寫使用者故事常見的問題 by David Ko

當然只靠 User Story 的描述對開發者來說是不友善的，所以我們需要靠一些方法讓 User Story 和我們的程式有所繫結；也就是說我們要從 User Story 中找出更詳細的規格，進而整合到前面 TDD 的測試目標裡。當通過了以規格所建立出來的測試，我們的程式碼也才真正地符合需求。

為了能達到開發、測試與需求三位一體的目標，所以 BDD - Behavior Driven Development (行為驅動開發) 就誕生了。

告訴我，這個功能會怎麼被使用

BDD 定義了需求方如何撰寫 User Story ，以及開發人員如何把 User Story 轉換成測試；所以 BDD 的重點並不是測試，而是在定義需求的規格。 BDD 在不同的程式語言中都有實作，例如：

• JBehave - Java 上的 BDD 框架，同時也是最早的 BDD 框架。
• RSpec - Ruby 上的 BDD 框架，使用 ruby 來直接描述規格。
• PHPSpec - PHP 上的 BDD 框架，使用 php 來直接描述規格。
• Cucumber - 一個用 Ruby 寫的 BDD 框架，後來因為推出 Cucumber-JVM 後，讓其他 JVM-based 語言也可以使用。它的特色是用文字格式的規格檔案來執行測試，後來就變成了一個業界非成文的標準，後來有很多 BDD 框架就參考它的運作方式來實作了。
• SpecFlow - .Net 上的 Cucumber 實作，同時也是這次上課所使用的框架。
• Behat - PHP 上的 Cucumber 實作。

Cucumber 利用 Gherkin 語法來描述需求規格，所以前面的 User Story 就會變成一個 feature 檔：

# features/products_searching

Feature: 使用者可以輸入關鍵字來找出站內的商品
    In order to 找出指定的商品
    As a 使用者
    I want to 輸入關鍵字

• 註：這裡我不會用課程裡的範例，一是我希望自己是真的理解了 BDD ，所以自己試著如何去應用；二是課程裡的範例更加有挑戰性，我不想破了講師的哏。

接著要定義出這個需求的使用場景，也就是更明確地說明這個需求的功能「要怎麼被使用」，我們稱為 Scenario 。

Scenario: 搜尋 "iphone" ，找出的商品包含了 5 個名稱中符合 "iphone" 的商品
    Given 在搜尋輸入框中輸入 "iphone"
    When 我按下搜尋按鈕
    Then 在搜尋頁得到 5 個名稱中符合 "iphone" 的商品

Scenario: 搜尋 "特價" ，會導向特價商品活動頁
    Given 在搜尋輸入框中輸入 "特價"
    When 我按下搜尋按鈕
    Then 導向特價商品活動頁

每個 Scenario 都是一條完整的功能執行路徑，只要有路徑分叉 (例如 if 判斷) 的話，就要有不同的 Scenario 。其中 Given-When-Then 就是用來描述一個 Scenario 的三要角，它們組合起來的意思是：

假定 (Given) 在某個條件下，當 (When) 我做了某個動作，然後 (Then) 就會發生什麼結果。

是不是有種既視感？沒錯！ Given-When-Then 剛好對應到 3A 原則的： Arrange-Act-Assert ，所以 Scenario 可以被轉換成測試！

我想用中文

前面在 feature 檔案保留英文單字，是為了讓 Gherkin 的語法解釋器能夠辨別；如果不喜歡這種寫法，也可以用中文，只要在檔案開頭加上 # language: zh-TW 就可以。

然後原來的 feature 檔就可以改成：

# features/product_searching.feature
# language: zh-TW

功能: 使用者可以輸入關鍵字來找出站內的商品
    為了 找出指定的商品
    身為 "使用者"  # 註：這裡以「者」結尾的話在 behat 裡會變亂碼，所以特別處理
    我要 輸入關鍵字

場景: 搜尋 "iphone" ，找出的商品包含了 5 個名稱中符合 "iphone" 的商品
    假定 在搜尋輸入框中輸入 "iphone"
    當 我按下搜尋按鈕
    那麼 在搜尋頁得到 5 個名稱中符合 "iphone" 的商品

場景: 搜尋 "特價" ，會導向特價商品活動頁
    假定 在搜尋輸入框中輸入 "特價"
    當 我按下搜尋按鈕
    那麼 導向特價商品活動頁

註：這裡因為我是用 Behat ，所以關鍵字的部份是採用 Behat 的語法 (可以用 behat --story-syntax --lang zh-TW 看到範例) 。

讓測試程式跟著需求跑

課程裡是使用 SpecFlow ，這裡我改用 Behat 來練習。先在專案裡面初始化 Behat 的執行環境：

behat --init

它會產生一個 features/bootstrap/FeatureContext.php ，而它就是連繫 feature 和測試的關鍵。

建立一個 features/products_searching.feature 檔，然後把前面定義的 featrue 內容貼上去，接著再執行 behat 指令就會得到以下輸出內容：

可以看到 Behat 把 feature 檔裡的 Given-When-Then 都變成了方法，它們稱為 Step Definition 。 Step Definition 是可以被重複使用的，所以可以看到兩個 Scenario 共用了其中兩個方法。不過因為 PHP 不支援用中文當做方法名稱，因此 Behat 幫我們用很奇怪的拼音組成方法名稱。

把 Behat 產生的方法複製到 FeatureContext.php 裡，然後把方法名稱改成易懂的英文，例如：

// ... 略 ...
class FeatureContext implements Context, SnippetAcceptingContext
{
    /**
     * @Given 在搜尋輸入框中輸入 :arg1
     */
    public function typingInSearchField($arg1)
    {
        throw new PendingException();
    }

    /**
     * @When 我按下搜尋按鈕
     */
    public function iEnterSearchButton()
    {
        throw new PendingException();
    }

    /**
     * @Then 在搜尋頁得到 :arg2 個名稱中符合 :arg1 的商品
     */
    public function getProductsThatIncludeInNameOnResultPage($arg1, $arg2)
    {
        throw new PendingException();
    }

    /**
     * @Then 導向特價商品活動頁
     */
    public function redirectToPageOfSpecialOffer()
    {
        throw new PendingException();
    }
}

接下來再執行一次 behat ，就會看到 Behat 要我們一步一步完成測試碼：

這實在是太酷了！現在我們已經讓測試跟規格文件繫結在一起，想要增加需求或修改需求，就是更改測試步驟。而且 Scenario 之間通常只是一兩個步驟的變化，所有已經測試過的步驟都可以重覆利用；而我們要做的就是隨著增長的規格，補上新增的 Step Definition 就可以！

至於怎麼寫測試呢？其實就和單元測試很像，只不過換了一種寫法，前兩週學的都可以應用在這裡面！這樣的開發方式真叫人欲罷不能！

註：心得不打算介紹太多實作，有機會我再補充 Behat 的做法。

不再是對立，而是能一起驗收需求

定義好了 feature 檔，我們只要把一個個的 Scenario 完成；就像雕刻一樣，一刀一刀切，最後就會看到完整的成品。而 PO 驗收專案時只需要對照 feature 所對應的測試是否為綠燈，只要通過了，也就是符合需求！這樣一來辦公室就再也不會有劍拔弩張的氣氛了！

當然一開始不見得會這麼順利，身為 BDD 的導入者，或許我們需要花更多耐心來引導 PO 協助我們去撰寫 Scenario ；當他漸漸瞭解這樣做的好處時，就會知道用這個方式能讓需求更快被滿足。未來只要整個團隊認同並遵循這樣的做法，我相信 BDD 一定能為專案帶來莫大的益處。

讓文件活下去

基本上， 多數的 Developer 通常很討厭：

• 寫文件
• 寫註解
• 寫測試

但是更討厭：

• 別的 Developer 都不寫文件
• 別的 Developer 都不寫註解
• 別的 Developer 都不寫測試

現在有了 feature 檔，也就同時有了文件和測試，更酷的是這兩者是隨著程式碼一起成長的！

而這門課最有價值的一節，就是教你如何把 feature 執行的結果轉換成 HTML 及 Word 文件，這樣一來只要搭配 CI 就可以讓所有作業一氣呵成！這樣的快感，是工程師夢寐以求的呀！

詳細方法當然還是上課才有的福利囉，至於 PHP 的方法我還在找尋中，這時就不得不說學 .Net 的朋友真是幸福。

總結

不要一直想著要寫出完美的測試，因為那通常已經偏離了真正的需求。讓程式符合需求才是開發者的最終目標，只是完整而詳細的需求卻不會自己長腳跑來。

讓真正瞭解需求的人協助你一起完成規格，讓這些規格協助你建立測試，而且執行測試。最後我們唯一要關注的，就是如何去滿足這些測試的目標。對整個團隊來說，真的能改善不少浪費的問題。

如果有機會再開課的話，我強烈推薦大家報名參加呀！趕快關注「自動測試與 TDD 實務開發」的下一梯課程吧！

如果你對這句話心有戚戚焉的話，那你真的不孤單。其實有很多維護維護前人程式碼的工程師在在接到新的需求而去修改程式碼時，常常是很戰戰競競的，然後辦公室裡就會響起這樣的聲音：

「我記得前一個工程師說這邊加幾行程式碼就可以了，你覺得呢？」
「我直覺這樣改會出問題...有環境讓我先測試看看嗎？」
「先不管，後天活動要上了，你先改完讓它上線後再說。」
「沒有測試的話...」
「閉嘴！快去改。」
不久後...
「慘了！訂單出大問題了！你可以先還原原來的程式碼嗎？」
「不對呀！我改這邊怎麼會讓那裡出錯？」
又過了一會兒...
「你有還原嗎？！整個訂單資料大亂了呀！你一定有動到什麼東西了！」
「我全還原了！現在跑的是我沒改過前的版本！」
「不管！加班修好它！」
「我不就說沒測試的話會有問題嗎！？為什麼不聽！？」
「你老闆我老闆？再靠杯試試看！」
三天後...
「夠了！拎杯走！我不想再改這個系統了！ (摔杯子) 」

假設今天有時間讓你調整這個系統，在不知道線上系統整體如何運作的狀況下，你會怎麼讓它容易被維護與增添新功能呢？

上週所介紹的單元測試其實還沒辦法可以讓我們立刻套用在這樣的系統上，所以本週課程的重點就在：如何為已經上線的 legacy code 加上測試。

為了達成這個目標，講師介紹了兩個招式： Web Testing 與 Refactoring 。以下我就以我的方式來介紹我所學到的心得。

Web Testing

看過聖鬥士星矢的話，應該都知道雅典娜說過：「你不是還有生命嗎？」

那麼回到問題點：現行的系統沒有測試怎麼辦？

對工程師來說，雅典娜的話就變成了：「你不是還有線上功能嗎？」

是呀！當系統是黑箱作業卻正常運作的時候，我們是從頁面 (介面) 上來確認的。換句話說，既然我們操作的方式是對的，而且畫面所得到結果也是我們所預期的，那麼對外部來說，這個已知功能就應該是正確的。所以我們可以先「對所有正確執行的功能建立測試」！只要在修改程式碼後，再跑相同的測試而沒有發生錯誤，就能證明我們的修改沒有影響到舊有程式碼。這實在是太酷了！

就網站來說，這樣的外部測試方式就稱為 Web Testing 。而如果所有的測試是以自動化腳本的形式存在，讓我們每次修改完程式碼後，可以方便地一次全部執行的話就太好了。最重要的，就是要有工具能幫我們產生這樣的腳本！而這種神一般的工具，就非 Selenium 莫屬了。

Selenium

Selenium 是一個讓瀏覽器自動化執行使用者操作流程的工具，通常用來當做測試的用途。它主要原理是利用 Selenium IDE 將使用者操作的過程錄製下來，並透過 Selenium IDE 或 Selenium WebDriver 執行該腳本，讓瀏覽器自動重現使用者操作過程。而它除了讓使用者操作的流程自動化之外，最厲害的地方是能夠把錄製下來的腳本轉換成不同的程式語言格式，融入到各語言的自動測試框架裡。

簡單介紹 Selenium 幾個要角：

1. Selenium IDE ： Firefox 的 Add-on ，用來錄製使用者在操作頁面時所有的動作與輸入，並且驗證輸出結果是否符合預期。而它的重播功能除了讓開發者快速驗證功能外，用來製作說明文件裡的操作範本也相當適合。
2. Selenium WebDriver ：告訴使用者的 IDE (例如 Visual Studio) 或 Selenium Server 如何啟動不同瀏覽器的中介層。常用的 WebDriver 包含了 IE 、 Firefox 、 Chrome 、 PhantomJS 等。 (原名 Selenium Remote Control)
3. Selenium Server (選備) ：用 Java 寫的 Daemon 服務；如果你的開發環境和測試用的瀏覽器不在同一台機器上，或是某些無法直接啟動瀏覽器的狀況下，你可能會需要透過 Selenium Server 來協助 WebDriver 啟動測試用的瀏覽器。 (原名 Selenium RC Server)

註：由於課程是使用 Visual Studio 來做本機開發與測試，所以只要用 Nuget 安裝 Selenium WebDriver 套件即可，不需要 Selenium Server 。

整個 Selenium 的使用流程如下：

1. 在 Firefox 上安裝 Selenium IDE 。
2. 視開發環境決定是否要啟動 Selenium Server ，或使用整合式的 Selenium WebDriver 。如果是 PHP 的話，不論是不是在本機執行，都一定要啟動 Selenium Server 。
3. 啟動 Web 服務，讓 Firefox 連上測試網站。
4. 針對所有功能錄製測試腳本 (包含操作流程與結果驗證) 。
5. 重跑所有腳本，確認沒有操作上的問題。
6. 利用 Selenium 的 Formatter 外掛，將 Selenium IDE 腳本轉換成對應的程式語言自動化測試框架的程式碼。
7. 讓自動化測試框架透過 Selenium WebDriver 來完整執行所有的 Selenium 測試腳本，並確認各瀏覽器有被正常開啟。
8. 接下來就可以繼續後續程式的新增功能或重構了。

而 Selenium WebDriver 詳細的使用方式在不同的語言有不同的作法，請分別參考我兩位好友的介紹：

• Vistual Studio 走這邊： [30天快速上手TDD]Integration Testing & Web UI Testing by Joey Chen (作者名字很熟對不對？)
• PHP 走這邊：PHP 也有Day #13 - 如何使用 Selenium 搞定前端測試 by Ricky Su

註：之前我也寫過 Web UI 測試的好幫手 - Selenium ，雖然內容有點舊，但原理沒差太多。

常見的問題

像 Web Testing 這種由外部建立測試的方法，雖然在遇到大多數沒有撰寫測試的 legacy 系統時非常有用，但也不能說毫無缺點。當系統對環境依賴度相當高時，想重建一個供測試用的系統會變得非常困難，而這通常也是必須先克服的問題之一。

然後規模稍大，功能點較多的網站就會面臨第二個問題：「誰來錄操作流程？」答案很簡單：當然不是工程師。通常 legacy 系統一定會有瞭解它是如何使用的人，這時候必須借重老闆的影響力，想辦法讓這些人能夠協助列出系統所有的功能流程。

由於 Selenium IDE 非常易用，可以先花點時間教會這些人學習怎麼錄製操作流程。接下來請他們在邊列功能時，順手將流程錄製起來；這樣一來當功能列完的同時，就有完整的測試可以使用，還順便帶有操作示範呢。

另外若是錯誤的操作會讓程式出現非預期的結果的話，就應該歸類在原本就有的 bug 。但這也表示我們知道有這個操作流程應該要被避免，因此也要特別為它建立一組測試；一來可以在修改程式後透過這組測試確認程式的修改是正確的，二來也確保未來不會再讓這個錯誤發生。就像「同樣的招式不能對聖鬥士使用第二次」，同樣的 bug 也不該在系統上發生第二次。

FluentAutomation 從愛開始

Seleinum WebDriver 程式碼好難看懂怎麼辦？如果未來我加新功能而沒辦法錄製腳本時，要照著這樣寫測試嗎？當然不！我們需要讓測試腳本變得抽象化一些，看起來就像是用人話在描述規格一樣。

又是借重好用工具的時刻，在微軟體系上有個好用的 FluentAutomation 第三方套件，就是能將 Selenium 腳本語法包裝起來的語義化框架。

例如我們有這樣的規格：

// 登入成功
    // 我打開 Login 的網頁
    // 在 id 裡面輸入 user
    // 在 password 裡面輸入 pass
    // 按下登入
    // 期望應該導到首頁

用 FluentAutomation 寫出來的話，就會是：

private string baseUrl = @"http://localhost:29021/";

[TestMethod]
public void TestLoginSuccess()
{
    I.Open(baseUrl + "login")
        .Enter("user").In("#id")
        .Enter("pass").In("#password")
        .Click("input[type=\"submit\"]")
        .Assert.Url(baseUrl);
}

因為測試的主角是「我」，所以一切從 I 開始；而測試的對象是「網頁」，所以我們會有 Open (開啟網址) / Enter (輸入) / Click (點擊) 等操作方式；最後再使用 Assert 來驗證畫面輸出是否如我們所預期。整段程式碼是不是看起來更語意化呢？

除了語法更為抽象之外， FluentAutomation 執行的結果其實和 Selenium WebDriver 是一樣的。 FluentAutomation 能讓開發者融入測試的情境中，從使用者行為的角度出發去看待系統功能。一切就像用人話在說明功能，看起來就是這麼自然。

註： FluentAutomation 也支援多種不同瀏覽器同時測試，相關的說明請參考官方文件。

註： PHP 也有類似的框架，是包含在 Codeception 的 WebDriver 模組中。

Page Objects Pattern

課程中介紹另一個我覺得很棒的觀念是，雖然功能是一樣的，但如果頁面結構調整了怎麼辦？這時候就要用到物件導向最重要的觀念：封裝變化。

Page Objects Patterns 把頁面當成是一個物件，只讓它露出必要的行為，讓我們的主要流程只描述如何跟這個頁面互動，而不在乎它頁面上的細節。這樣一來不管頁面結構怎麼變化，只要主要功能不變，我們都只需要修改這個 Page Object 就好。

Page Objects 在 FluentAutomation 的實作範例可以參考官方說明的 PageObjects 一節。

同樣地在 PHP 的 Codeception 也支援 Page Objects Patterns ，請參考 PageObjects 一節。

Refactoring

假設我們已經有了 Web Testing 來確保我們的功能都經過了外部測試，那麼我們就有機會對它進行重構了。

課程中的範例可以說是這兩週課程的精華呀，從一個很難撼動的程式碼，一步一步重構成包含了 Web Testing 和單元測試的可維護可擴充架構。

這裡很難把它用三言兩言完整描述出來，恕我偷懶一下，這裡請直接參考講師以前寫的 30 天快速上手 TDD 之重構系列文章：

• [30天快速上手TDD][Day 9]Refactoring legacy code 簡介
• [30天快速上手TDD][Day 10]Refactoring 起手式 - 建立測試
• [30天快速上手TDD][Day 11]Refactoring - 讓程式碼說話
• [30天快速上手TDD][Day 12]Refactoring - 職責分離
• [30天快速上手TDD][Day 13]Refactoring - 告訴我，你要什麼
• [30天快速上手TDD][Day 14]Refactoring - 驗貨
• [30天快速上手TDD][Day 15]Refactoring - 食神歸位
• [30天快速上手TDD][Day 16]Refactoring - 介面導向
• [30天快速上手TDD][Day 17]Refactoring - Strategy Pattern
• [30天快速上手TDD][Day 18]Refactoring - Factory Pattern
• [30天快速上手TDD][Day 19]Refactoring - The End is the Beginning

簡單說明一下整套重構流程的重點：

1. 用 Selenium 錄下你的 Web 測試，越完整越好，而且讓它可以隨時執行。
2. 理解你要重構的 legacy 程式碼意圖，把註解補上去。不用管細節，只要知道某段程式打算做什麼就好。
3. 重構：想辦法把邏輯和 UI 分離開來，這個可能會因為語言或框架的不同而有不同的做法。
4. 重構：應用常用的 Extract Method 技巧來將程式碼拆分出易懂的方法。
5. 重構：依照職責分離的原則，把剛剛分離出來的方法引到新的類別中。
6. 獨立出類別後，就可以把單元測試補上去了。接著所有測試都跑跑看吧。
7. 重構：為各相似的類別抽出介面 (Interface) ，讓主程式去依賴介面，而不要依賴剛剛的類別。
8. 重構：在抽出介面後，利用 Factory Method 將生成物件 (new) 的職責獨立出去。

要特別記住：

• 每一步重構後都要測試，而且只要測試是綠燈，都是應該是能夠上線的狀態。
• 通過測試後，就把程式碼 commit 到 VCS 裡，別偷懶。
• 重構在搬移程式碼時，只修改 context ，而不要修改流程結構。
• 修改流程結構 (例如 if 換成 switch ) 要自成一個重構。

避免增加中介層的獨立測試

這段是講師的壓箱寶，據說是這次課程才加入的，有聽有賺到。

這邊我打算用一句話來帶過：懶爸爸有個相依耦合的類別，把它抽出來放到可覆寫的方法中回傳；用個笨兒子來繼承懶爸爸，接著笨兒子用 DI 來注入相依物件的 stub object ；最後改測試笨兒子，結束。

如果看得懂上面這句，我想就能得到講師這段課程的精髓了。至於這個技巧多有用？如果發現類別中相依耦合度很高，卻又不確定這些類別被哪些程式用到，更擔心修改方法簽名就會影響整個系統時，你就會知道這個技巧的威力了。

心得

我必須老實說，不論是補測試或是重構，技術上絕對不是什麼大問題；像這次的課程所介紹的技巧，都沒有什麼非常困難的部份。那麼為什麼很多人不做呢？我想是因為大家都拿「新功能都做不完了，哪來時間做重構？」做為藉口了。但回到最文章最開頭的情境，其實真的花你時間的，反而不是這些測試或重構，而是你跟同事因為系統出問題的爭執。

如果老闆有心解決舊有系統的問題，就想辦法說服他加上測試並重構吧。

想瞭解更多的話，請報名「自動測試與 TDD 實務開發 」。

從我自己開始研究測試後，其實一直覺得自己還是沒有真正把測試當成是開發的一部份，更別說坊間很多程式書籍和教學課程能把這兩者真真實實地融合在一起，傳授給廣大的開發人員。

這次正好有機會去聽 Joey (91 哥) 在 SkillTree 開的 TDD 課程，我心想這實在是太棒了！ Joey 是業界在 TDD 領域相當有研究，而且也已經在實務上經過千錘百鍊的高手，如果能親眼見到他是如何把測試融入開發中的話，一定能大大提升自己的經驗值！

不過課程中精采的部份太多了，恕我無法一一介紹；而且我也不覺得我能在這篇心得中，表達出講師在實務面的深厚功力。以下就讓我來為大家介紹這個課程為什麼值得你去聽的心得。

絕對有料的課程內容

我個人很喜歡這個課程一開始就把整個學習地圖展開來，讓學員知道接下來幾週裡會由淺入深地學到哪些技巧，例如本週 (第一週) 是單元測試的基礎。雖然說是基礎，但卻是最關鍵的一環！因為講師會將所有至今你對測試的錯誤認知重新洗掉，注入最正確的觀念！

而接下來講師就舉出了幾個血淋淋的真實案例，告訴你為什麼測試是重要的。測試不是用來應付流程的工具，而是紥紥實實讓你對自己的程式碼能更有信心的魔法。你不見得能在一開始就體會測試的重要性，但你一定會在出大包時懊悔：如果當時有測試就好了 (曾經待過 EC 產業的我感同身受) 。

講師也三不五時會讓學員用回答問題的方式，讓學員重新審視對剛剛所教授的內容是否有真的瞭解，講師也會適時地再補充。講師也會針對同學的發問，來分享自己在實務上遇到的問題。

一定能懂的教學方式

有趣的是，這次課程講師是用 C# 教學，但在 PHP 中打滾的我卻對範例沒有絲毫的疏離感。因為講師舉的例子相當生活化，而且寫出來的程式碼非常平易近人，只要有寫過程式的人一定都能看懂。

課程中包含了讓學員動手的實戰練習，每個範例都是從實務中淬鍊出來的，像是如何測試亂數？如何測試只會在特定日期啟用的功能等等；而且範例經過縝密的安排，能循序漸進地讓學員瞭解如何在測試中套用課程中講授的原則。你會很驚訝原來這些我們以為難測試的問題，其實在測試中解決的方式竟然是這麼簡單。

當然對不會寫 C# 的我來說，原本以為沒辦法用 IDE 實際演練會是件憾事；但這些實例設計之精巧，卻能夠讓我用 PHP 來重新代入；所謂一法通萬法通，測試的觀念本來就不限程式語言，這樣讓人興奮的實戰訓練，會讓人有手停不下來的感覺。

教你怎麼快速建立測試又能寫出好測試

我們都知道開發應該針對需求，然而測試也是。但我們卻容易想得太多，導致我們做了太多無謂的工作。在課程中，講師會告訴你如何讓測試去配合需求，而不是為了測試而測試。搭配測試的原則，我們就不會再認為測試是多出來的工，而應該是開發的一部份。

例如關注點分離、 FIRST 、 3A 這類的測試原則，都是寫測試時所應該遵守的，但很少人知道要怎麼去應用。然而透過這個課程的範例教學，你會發現這麼多名詞和原則，竟能從中得到驗證！因為它們其實都是從實務所演化出來的，只是我們一直以教條式的方法來學習它們；當真正看到這些原則是這麼輕鬆地被講師透過實例展現出來時，那種震憾是文字難以描述的。

當然我們在實際撰寫測試碼時，還是很容易覺得它是件麻煩事，這時候測試工具就非常重要了。一個好的測試框架會影響你撰寫測試的意願，如果這工具沒辦法很容易又很簡潔地寫出符合意圖的測試，那麼也就不能怪其他同事質疑寫測試是不是有幫助了。

而號稱地表最強 IDE 之一的 Visual Studio 在這方面當然不會落於人後，簡單幾個指令和操作，測試骨架就立刻出現。再搭配第三方的測試工具，輕輕鬆鬆地就在這些骨架加血添肉，轉眼間測試就完成了。寫測試這件事從此融入整套開發流程裡，怎麼可能讓人不興奮呢？

實務上面臨的問題

Demo (SkillTree 主辦人) 在課餘時間聊到：「即便寫測試變得容易，而我們也開始把它變成自己的習慣，但你還是一定會碰到同事有這樣的質疑：『這程式碼就是正確的呀！為什麼還需要測試？』」我想一定有想在團隊裡導入測試的朋友常會遇到這種狀況，在這個課程中也可以讓你學到用什麼方法可以處理這樣的質疑。

在導入測試時時，最重要的就是讓同事對測試有信心；當寫測試變得很容易時，你所要做的，就是怎麼讓同事也能體會寫測試能為他帶來什麼效益。這方面講師也會提出他的實務經驗供我們參考，而且不論是技巧上和人性上，都是相當值得參考的建議。

最後還有一個可能會面臨到的，就是測試對程式碼的涵蓋率。講師的回答其實讓我非常驚訝 (容我賣個關子) ，這其實讓我對「測試對團隊的影響力」這件事大大地改觀。雖然我自己也在某個部份應用上了類似的觀念，但我以為這只是影響了我自己，沒想到這確實是一種對人性的實務作法，不禁讓我對它更有信心；我相信透過這些小小的改變，就有機會讓整個團隊變得更有勇氣去面對測試這件事情。

小結

上完第一週的課程，我腦海裡一直迴響著：『你必須對你的測試有信心，測試才能讓你對你的程式有信心。』

測試應該要做什麼？怎麼寫有效的測試？怎麼快速地寫測試？怎麼讓同事一起來寫測試？原本以為自己已經可以回答這些問題，卻在這個課程中讓我的觀念整個大洗牌，也開始讓我心中已經消逝很久的熱血又漸漸沸騰起來。

再次感謝講師 Joey 和 SkillTree 的 Demo 舉辦這麼實用且精采的課程，我越來越期待接下來幾週的內容了。

然後 Octopress 實在是很慢，所以就換到 Hexo 這個以 Node.js 開發的 Blog Framework 。

原來的文章網址也不打算留了，讓 Google 重新爬吧； GA 什麼的就找時間再調整。

還是想有個能專心寫文的地方，希望能有空把手邊的草稿整理完。

所以接下來我將用一個簡單的範例，來為各位介紹在 PHP 中如何實現簡易的 DI 。

基本範例

這是一個應用程式的範例，它只包含了登入處理程序。在這個範例中， App 類別的建構式參考了新的 Auth 與 Session 的物件實體，並在 App::login() 中使用。

註：請特別注意，為了呈現重點，我忽略掉很多程式碼，同時也沒有進行良好的架構設計；所以請不要把這個範例用在你的程式中，或是對為什麼我沒有進行錯誤處理，以及為什麼要採用奇怪的設計提出質疑。

class App
{
    protected $auth = null;
    protected $session = null;

    public function __construct($dsn, $username, $password)
    {
        $this->auth = new Auth($dsn, $username, $password);
        $this->session = new Session();
    }

    public function login($username, $password)
    {
        if ($this->auth->check($username, $password)) {
            $this->session->set('username', $username);
            return true;
        }
        return false;
    }
}

而 Auth 類別是從資料庫驗證使用者身份，這裡我僅用簡單的描述來呈現效果。

class Auth
{
    public function __construct($dsn, $user, $pass)
    {
        echo "Connecting to '$dsn' with '$user'/'$pass'...\n";
    }

    public function check($username, $password)
    {
        echo "Checking username, password from database...\n";
        return true;
    }
}

Session 類別也是概念性的實作：

class Session
{
    public function set($name, $value)
    {
        echo "Set session variable '$name' to '$value'.";
    }
}

最後我們讓程式動起來， client 程式如下：

$app = new App('mysql://localhost', 'username', 'password');
$username = 'jaceju';
if ($app->login($username, 'password')) {
    echo "$username just signed in.\n";
}

註：這裡的 client 程式指的是實際操作這些物件實體的程式。

各位可以先試著想想這個程式在可擴充性上有什麼問題？例如我想把身份認證方式換成第三方服務的機制，或是改用其他媒介來存放 session 內容等。

還有如果想在沒有資料庫連線、或是沒有 HTTP session 的環境下對 App::login() 方法的邏輯進行隔離測試，各位會怎麼做呢？

解除依賴關係

上面的範例因為 App 類別已經依賴了 Auth 類別和 Session 類別，而這兩個類別都有實作跟系統環境有關的程式邏輯，這麼一來就會讓 App 類別難以進行底層機制的切換或是隔離測試。所以接下來我們要做的，就是把它們的依賴關係解除。

修改後的 App 類別如下：

class App
{
    protected $auth = null;
    protected $session = null;

    public function __construct(Auth $auth, Session $session)
    {
        $this->auth = $auth;
        $this->session = $session;
    }
}

$auth = new Auth('mysql://localhost', 'username', 'password');
$session = new Session();
$app = new App($auth, $session);

首先我們在 App 類別的建構式 __construct 原本的資料庫設定參數移除，並將原來直接以 new 關鍵字所產生的物件實體，改用方法參數的方式來注入。而使用 new 關鍵字產生物件實體的程式碼，就移到 App 類別外。

這種「將依賴的類別改用方法參數來注入」的作法，就是我們說的「依賴注入 (Dependency Injection) 」。

常見依賴注入的方式有兩種： Constructor Injection 及 Setter Injection 。它們的實作形式並沒有什麼不同，差別只在於是不是類別建構式而已。

不過 Constructor Injection 必須在建立物件實體時就進行注入，而 Setter Injection 則是可以在物件實體建立後才透過 setter 函式來進行注入。而這裡為了方便解說，我採用的是 Constructor Injection 。

依賴抽象介面

好了，現在的問題是 Auth 類別的實作還是依賴在資料庫上，所以我們也要讓 Auth 類別跟資料庫之間解除依賴關係，讓它成為一個抽象介面。

這裡的抽象介面是指觀念上的意義，而非語言層級上的抽象類別 (Abstract Class) 或介面 (Interface) 。至於在實作上該用抽象類別還是介面，在這個範例裡並沒有差別，大家可以自行判斷；這裡我用介面 (Interface) ，因為我僅需要 Auth::check() 這個介面方法的定義而已。

這一步首先我把原來的 Auth 類別重新命名為 DbAuth 類別：

class DbAuth
{
    public function __construct($dsn, $user, $pass)
    {
        echo "Connecting to '$dsn' with '$user'/'$pass'...\n";
    }

    public function check($username, $password)
    {
        echo "Checking username, password from database...\n";
        return true;
    }
}

接著建立一個 Auth 介面，它包含了 Auth::check() 方法的定義：

interface Auth
{
    public function check($username, $password);
}

然後讓 DbAuth 類別實作 Auth 介面：

class DbAuth implements Auth
{
    // ...
}

最後把原來初始化 Auth 類別的物件實體的程式碼，改為初始化 DbAuth 的物件實體。

$auth = new DbAuth('mysql://localhost', 'username', 'password');
$session = new Session();
$app = new App($auth, $session);

透過 Auth 介面的幫助，我們已經讓 App 類別與實際的資料庫操作類別分離開來了。現在只要是實作 Auth 介面的類別，都可以被 App 類別所接受，例如我們可能會改用 HTTP 認證來取代資料庫認證：

class HttpAuth implements Auth
{
    public function check($username, $password)
    {
        echo "Checking username, password from HTTP Authentication...\n";
        return true;
    }
}

$auth = new HttpAuth();
$session = new Session();
$app = new App($auth, $session);

當然其他類型的認證方式也可以透過建立新的類別來使用，而不會影響到 App 類別的內部實作。

DI 容器

現在又有個問題， client 程式還是依賴於 DbAuth 類別或是 HttpAuth 類別；通常這種狀況在需要編譯型的語言 (例如 Java ) 中，程式一旦編譯完成佈署出去後，就很難再進行修改。

如果我們可以改用設定的方式來告訴程式，在不同的狀況下對應不同的類別，然後讓程式自行判斷環境來產生需要的物件實體，這樣就可以解開 client 程式對實作類別的依賴關係。

這裡要引入一個技術，稱為 DI 容器 (Dependency Injection Container) 。 DI 容器主要的作用在於幫我們解決產生物件實體時，應該參考哪一個類別。我們先來看看用法：

Container::register('Auth', 'DbAuth', ['mysql://localhost', 'username', 'password']);

$auth = Container::get('Auth');
$session = new Session();
$app = new App($auth, $session);

首先我們在 DI 容器中先以 Container::register() 方法來註冊 Auth 這個別名實際上要對應哪個類別，以及建立物件實體時會用到的初始化參數。要注意，這裡的別名並不是指真正的類別或介面，但我們可以用相同的名稱以避免認知上的問題。

然後我們用 Container::get() 方法取得別名所對應類別的物件實體，上面例子裡的 $auth 就是 DbAuth 類別的物件實體。

這麼一來，我們就可以把註冊的程式碼移出 client 程式之外，並將註冊參數改用設定檔引入，順利解開 client 程式對實作類別的依賴。

DI 容器原理

那麼 DI 容器的原理是怎麼運作的呢？首先在 Container::register() 方法註冊的部份，它其實只是把參數記到 $map 這個類別靜態屬性裡。

class Container
{
    protected static $map = [];

    public static function register($name, $class, $args = null)
    {
        static::$map[$name] = [$class, $args];
    }

    // ...
}

重點在 Container::get() 方法，它透過 $name 別名，把 $map 屬性中對應的類別名稱和初始化參數取出；接著判斷類別是不是存在，如果存在的話就建立對應的物件實體。

class Container
{
    // ...

    public static function get($name)
    {
        list($class, $args) = isset(static::$map[$name]) ?
                              static::$map[$name] :
                              [$name, null];

        if (class_exists($class, true)) {
            $reflectionClass = new ReflectionClass($class);
            return !empty($args) ?
                   $reflectionClass->newInstanceArgs($args) :
                   new $class();
        }

        return null;
    }
}

比較特別的是，如果初始化參數不是空值 (null) 時，則必須透過 ReflectionClass::newInstanceArgs() 方法來建立物件實體。 ReflectionClass 類別可以映射出指定類別的內部結構，並提供方法來操作這個結構； Reflection 是現代語言常見的機制， PHP 在這方面也提供了完整的 API 供開發者使用，請參考： PHP: Reflection 。

Container::get() 方法也可以在沒有註冊的狀況下，直接把別名當成類別名稱，然後協助我們初始化對應的物件實體；例如：

$session = Container::get('Session');

手動注入

現在我們的 client 程式已經修改成以下的樣子：

$auth = Container::get('Auth');
$session = Container::get('Session');
$app = new App($auth, $session);

不過當初始化參數較多的狀況下，重複寫好幾次 Container::get() 看起來也是挺囉嗦的。

接下來我們實作一個 Container::inject() 方法，提供開發者可以一次注入所有依賴物件實體：

$app = Container::inject('Auth', 'Session', function ($auth, $session) {
    return new App($auth, $session);
});

這裡我們讓 Container::inject() 接受不定個數的參數，除了最後一個參數必須是 callback 型態外，其他都是要傳遞給 Container::get() 的參數。 Container::inject() 的實作方式如下：

class Container
{
    // ...

    public static function inject()
    {
        $args = func_get_args();
        $callback = array_pop($args);
        $injectArgs = [];

        foreach ($args as $name) {
            $injectArgs[] = Container::get($name);
        }

        return call_user_func_array($callback, $injectArgs);
    }

在參數個數不定的狀況下，可以用 func_get_args() 函式來取得所有參數；而 array_pop() 可以取出最後一個參數值做為 callback 。剩下的參數就透過 Container::get() 來取得物件實體，最後再透過 call_user_func_array() 函式將處理好的參數傳遞給 callback 執行。

自動解決所有依賴注入

在我們的範例裡， Container 類別如果可以提供一個方法，自動為我們解決所有 App 類別依賴問題，那麼程式就可以更乾淨些。

要做到這點，我們就必須知道要注入的方法所需要參數的類型；而在 PHP 中的 Type Hinting ，就可以告訴我們參數所對應的變數類型或類別。

回到 App::__construct() 建構子上，我們看到 $auth 與 $session 兩個參數的 type hint 分別對應到 Auth 與 Session 這兩個類別，剛好就可以用來當做我們做自動依賴注入的條件。

class App
{
    public function __construct(Auth $auth, Session $session)
    {
    }
}

接著我們為 Container 類別提供一個 resolve() 方法，它可以接受一個類別名稱用來建立物件實體，而不需要再使用 new 關鍵字。

$app = Container::resolve('App');

我們希望 Container::resolve() 方法會自動產生參數所對應的物件，解決這個類別建構子所需要的依賴關係。它的實作如下：

class Container
{
    // ...

    public static function resolve($name)
    {
        if (!class_exists($name, true)) {
            return null;
        }

        $reflectionClass = new ReflectionClass($name);
        $reflectionConstructor = $reflectionClass->getConstructor();
        $reflectionParams = $reflectionConstructor->getParameters();

        $args = [];
        foreach ($reflectionParams as $param) {
            $class = $param->getClass()->getName();
            $args[] = static::get($class);
        }

        return !empty($args) ?
               $reflectionClass->newInstanceArgs($args) :
               new $class();
    }
}

Container::resolve() 方法與 Container::get() 方法的原理類似，但較特別的是它使用了 ReflectionClass::getConstructor() 方法來取得類別建構子的 ReflectionMethod 實體；接著再用 ReflectionMethod::getParameters() 取出參數的 ReflectionParameter 物件集合 (陣列) 。

而後我們就可以在迴圈中一一透過 ReflectionParameter::getClass() 方法與 ReflectionClass::getName() 方法來取得 type hint 所指向的類別或介面名稱。當有了參數所對應的類別或介面名稱後，就可以用 Container::get() 方法來取得參數的物件實體。

最後把這些物件帶回建構子的參數裡，並初始化我們所需要的物件實體，就完成了 App 類別的自動依賴注入。

深入思考

再強調一次，這裡的範例只是為了介紹 DI 容器的原理，並不能真正用在實務上。因為一個完整的 DI 容器還要考慮以下的問題：

• 類別不存在時的處理。
• 與其他非類別的參數整合。
• 如何建立設定檔機制以便切換依賴關係。
• 遞迴地自動注入物件實體。
• 取得 Singleton 物件實體。
• 可以透過原始碼上的 DocBlock 註解來註明依賴關係。

目前已經有很多 DI Framework 幫我們處理好這些事情了，建議大家如果真的需要在專案中使用 DI 時，應該採用這些 Framework 。

總結

如果專案並不會有太多變化性，那麼依賴注入對我們來說就不是那麼重要。但是如果希望程式對特定類別的依賴性降低，只針對抽象介面實作，那麼依賴注入就有其必要性。

在 PHP 上的 DI 容器的基本實作原理也不複雜，透過 Reflection 機制就可以看到類別內部的結構，讓我們對它的建構子注入我們想要的參數值。

DI 容器要考量的部份也不少，但這些功能都已經有 Framework 實作，我們應該在專案中使用它們而儘可能不要自行開發。

希望透過以上的介紹，可以讓大家對 Framework 的依賴注入機制有基本的認知。

註：上述程式碼都可以在 php-di-container-examples 找到。

10 Common PHP Coding Errors

1. 在 foreach 迴圈中使用了迭代項目的參考。
2. 誤用了 isset 。
3. 搞混了回傳值是傳參考還是傳值。
4. 在迴圈中執行不必要的 SQL Query 。
5. 一次取得太多結果，造成不必要的記憶體浪費。
6. 忽略了 Unicode / UTF-8 問題。
7. 總是假設 $_POST 會包含 POST 資料。
8. 沒有注意 PHP 不支援 char 字元型態。
9. 對編碼標準的忽略，尤其是 PSR 標準 (當然有些依據不見得好，但也是大家討論出來的標準) 。
10. 誤用了 empty 函式。

Common PHP Mistakes

1. 忘了使用快取機制來減少大量 requests 對系統的衝擊。
2. 沒有避開 SQL Injection 。
3. 開發時關掉了錯誤回報。
4. 表單 POST 後還停留在同一頁。
5. 沒有善用已經存在的工具，而重造輪子。
6. 關掉了 timeout 機制，讓 script 沒有停止的依據。
7. 忽略了網站可用性。

7 More Mistakes Commonly Made by PHP Developers

1. 使用過時的 mysql extention 。
2. 沒有使用 PDO 的參數機制來避免 SQL Injection 。
3. 沒有重寫網址，讓它符合現今的網址守則。
4. 抑制錯誤訊息的發生。
5. 在條件判斷式中賦值。
6. 曝露太多有關系統所使用的 Framework 資訊。
7. 沒有移除掉開發時的設定檔。

在 JSConf.Asia 2013 ， Lea Verou 介紹了 CSS in the 4th dimension (影片) ，引發了整個 Web 界對 CSS 動畫的期盼；在 CSS動畫簡介一文也已經把重點整理好了。

以下我們將會介紹主要兩個 CSS3 在動畫的屬性： Transition 與 Animation ，並配合實例來練習這些技術，後面我也會介紹一些不錯的相關開發工具。

Transition

在以往 HTML 元素在兩種外觀之間的變換，只能從一種外觀直接跳到另一種外觀，瀏覽者並沒有辦法感受到這兩種外觀中間平滑的轉換，造成了視覺上的不適。

例：在滑鼠移過時，方塊的高度和寬度變化。

基本的 transition

而 CSS 為了補足這方面的視覺轉換特效，特別加入 transition 屬性。 一個簡易的動畫效果就是在想要變化的狀態上，加入一個 transition 屬性，而其值為變化需歷時的秒數。

div:hover {
    ...
    transition: 1s;
}

這麼一來， transition 就會自動幫我們補足中間的過場動畫。例如我們希望上面的例子能平順地轉換，歷時一秒：

例：加入 transition 後的效果

我們也可以讓高度以外的屬性有動畫效果，例如顏色：

例：用 transition 改變顏色

transition 屬性詳解

transition 屬性其實跟 font 或 background 屬性一樣是簡寫屬性，它是以下四個屬性的總和：

• transition-property: 要做變換的 CSS 屬性
• transition-duration: 變換需要的時間，單位為 s 或 ms
• transition-delay: 延遲多久後開始變換，單位為 s 或 ms
• transition-timing-function: 稱為 Timing Funciton ，用名稱來定義變換時的加速度。

這些屬性可以分開寫，也可以將它們的值同時寫在 transition 屬性裡；唯一要注意的是 transition-duration 與 transition-delay 的值寫在一起時有前述的順序關係。前面例子中的 transition: 1s ，其 1s 即為 transition-duration 的值。

transition-property 可使用 transition 的屬性

不是所有 CSS 屬性都可以使用 transition ，可以參考這篇 CSS animated properties 得知有哪些屬性可以使用 transition 。

transition 預設是對所有可套用的屬性做轉場效果，也就是關鍵字 all ；但其實也可以只針對某個屬性做 transition 變化，其他屬性則維持原來的直接變化。

例：只對單一屬性加入 transition

針對不同屬性同時做 transition

如果希望對兩個以上的屬性做 transition ，可是又不希望影響其他屬性時，可以用逗號 , 將要做 transition 的屬性分隔開來。

例：對不同屬性同時做 transition

transition-delay 延遲變換

有時候我們需要先變換一個屬性，再變換另一個屬性，這時候就需要對後者加入一個延遲時間；它需要加在原先我們定義好的歷時時間之後。

例：先變換一個屬性，再變換另一個屬性

transition-timing-function Timing Funciton

Timing Funciton 包含數種模式，下圖可以看出它們的加速度曲線。

• linear: 匀速
• ease: 急加速後減速 (預設值)
• ease-in: 加速
• ease-out: 减速
• ease-in-out: 較平緩的 ease
• cubic-bezier: 自定義速度模式

cubic-bezier 函式

利用貝茲曲線函式來定義加速曲線，可以直接使用線上工具 cubic-bezier() 來找出需要的數值。

雙向的 transition

Transition 的效果只會作用在有加入 transition 屬性的那個狀態，一旦要回復至原來的狀態時，就會失去 Transition 的平順效果了。這時我們需要對原先的狀態，也加入 transition 。

例：雙向的 transition

Transition 的限制

transition 的開始和結束都必須是具體數值；例如以下的 CSS 屬性值之間是無法被計算的，就無法使用 transition ：

• height: auto (不確定的值) 至 height: 100px (具體數值)
• display: none 至 display: block
• background: url(foo.jpg) 至 background: url(bar.jpg)

例： transition 無法作用的狀況

另外 transition 需要事件來觸發它的動作，所以沒辦法在一進頁面自動產生效果。所以如果不透過 JavaScript 事件處理的話，就只能配合與事件有關的 Pseudo Classes (偽類別，即 :hover 、 :focus 等) 來呈現效果了。

例：搭配 :focus 偽類別

搭配 jQuery

如果搭配 jQuery 等可以操作 DOM 元素的 library ，我們就可以做更複雜的操作。

例：透過切換 class 來做 transition

瀏覽器支援

目前包含 IE 10+ 的主流瀏覽器都已經支援 transition ，可參考 Can I use 。

Animation

雖然 transition 屬性簡單易用，但也有上述的侷限。因此就有了 animation 這個屬性來彌補其不足。

基本的 Animation

最基本的 animation 要指定動畫持續的時間，還有動畫的名稱。

div:hover {
  animation: 1s fat;
}

而動畫的定義則是用 @keyframes 這個屬性，例如：

@keyframes fat {
  0% { width: 100px; }
  50% { width: 150px; }
  100% { width: 200px; }
}

在 @keyframes 中可以定義多個狀態，範圍可從 0% 至 100% 。另外 0% 可寫成 from ， 100% 可寫成 to ，其他狀態還是使用數字百分比。

例：基本的 animation

animation 屬性詳解

animation 屬性和 transition 屬性一樣，都是簡寫屬性。它代表以下屬性的總和：

• animation-name: 動畫名稱
• animation-duration: 播放一次動畫需要的時間，單位為 s 或 ms
• animation-timing-function: 動畫的加速度曲線
• animation-delay: 延遲多久後啟始動畫
• animation-iteration-count: 動畫播放次數，可用 infinite
• animation-direction: 動畫播放方向
• animation-fill-mode: 指定動畫播放前後的狀態
• animation-play-state: 指定動畫播放或暫停

其中 animation-duration 、 animation-timing-function 、 animation-delay 可參考上面 transition 相似屬性的介紹。

animation-iteration-count 播放次數

預設 animation 和 transition 一樣只會動作一次，但我們可以加入數字來指定動畫效果播放的次數。

例：指定 animation 的播放次數

或是以 infinite 這個關鍵字來無限次播放。

例：無限次播放 animation

animation-direction 播放方向

所謂的播放方向是指從動畫效果 0% 到 100% 的方向，同時也是預設的 normal 值。可供設定的值如下：

• normal ：每次播放都是從 0% 至 100%
• reverse ：每次播放都是從 100% 至 0%
• alternate ：播放兩次以上的話，會從 0% 至 100% ，再從 100% 回到 0% ，以此類推
• alternate-reverse ：跟 alternate 相反，會先從 100% 開始播放

animation-direction: reverse ：

例：animation 播放方向 reverse

animation-direction: alternate ：

例：animation 播放方向 alternate

animation-direction: alternate-reverse ：

例：animation 播放方向 alternate-reverse

animation-fill-mode 動畫播放前後的狀態

如果想要控制動畫播放完後的最終狀態，可以用 animation-fill-mode 屬性，它可設定的值如下：

• none ：回到未播放動畫效果前的狀態
• forwards ：停在動畫的最後一個狀態上
• backwards ：停在動畫的第一個狀態上 (實測不出來)
• both ：視 animation-direction 來決定停在哪一個狀態上。

例：指定 animation 播放後的狀態 forwards

註： backwards 這個值我在 Chrome 和 Firefox 都試不出來。

animation-play-state 指定動畫播放或暫停

animation-play-state 有兩個屬性值： running 及 paused ，其中 running 是預設值。

這個屬性必須獨立定義，無法被放在 animation 屬性裡。

例：決定 animation 執行或暫停

瀏覽器支援

animation 屬性目前在 IE 10+ 以上主流瀏覽器都可以執行，但採用 Webkit 引擎的瀏覽器必須加上 -webkit- 前綴字串。

div:hover {
  -webkit-animation: 1s name;
  animation: 1s name;
}

@-webkit-keyframes name {
    ...
}

@keyframes name {
    ...
}

實例

接下來我們用 Animation 搭配 Transform 來做簡單的旋轉動畫。 Transform 是用來讓 HTML 元素變形的屬性，雖然跟動畫沒有直接的關係，但它是可以套用動畫效果的。這邊我不打算詳細介紹它，只會用到旋轉的效果。

它的語法如下：

div {
    transform: rotate(θ);
    transform-origin: x y;
}

rotate(θ) 是指讓指定元素以參考點為中心軸 2D 旋轉 θ 度， transform-origin 會將 (x, y) 設為參考點。當我們把 transform: rotate(θ) 放到 @keyframes 中時， animation 就會改變 θ 值來做出動畫效果。

以下模擬簡單的太陽、地球、月亮的週期變化。

範例：模擬太陽、地球、月亮的週期

更酷的範例參考：

• 20 stunning examples of CSS3 animation
• Our Solar System
• 30 Best Creative CSS3 Animation Examples
• Codepen.io CSS Animation

開發工具

CSS 3.0 Maker

CSS 3.0 Marker 可以讓我們調整 CSS3 相關屬性的參數，並預覽效果。確認後就可以產生對應的 CSS 碼，套用到專案上。

Animate.css

Animate.css 這個 CSS framework 提供很多組已經定義好動畫效果的 CSS class ，讓我們可以直接套在 HTML 元素上，或是搭配 jQuery 來操作 class 來產生動畫效果。

範例： Animation.css

Animate Mixin for Compass/SASS

Animate Mixin for Compass/SASS 提供了一組很棒的 CSS3 Animation mixins ，讓我們可以直接套用。它其實就是從 Animation.css 移植過來的。

AniJS

AniJS 是一個宣告式的 CSS 動畫 library ，它讓我們可以在 HTML 元素中加入一個 data-anijs 屬性，並用敘述式來定義動作事件、動畫效果、以及要作用在哪個元素上。要特別注意的是，它也必須搭配 Animation.css 使用。

範例： AniJS

$ [sudo] npm install --g yo generator-angular
$ mkdir <app-name>
$ cd <app-name>
$ yo angular [app-name]
$ npm install karma-chrome-launcher karma-jasmine --save-dev
$ bower install --save angular-cookies

預覽專案：

$ grunt serve

建立對應的 JavaScript 檔案：

$ yo angular:controller [controllerName]
$ yo angular:view [viewName]
$ yo angular:route [routeName]
$ yo angular:directive [directiveName]

測試專案：

$ grunt test

建置專案：

$ grunt build

另外需要注意幾個重點：

• 跟 bower 的結合非常緊密，如果沒有什麼客製化需求的話，直接用就 bower 來管理 assets 就好。
• 因為有用 bower 和 grunt 直接在 index.html 上管理相依性和最小化的問題，所以不需要使用 RequestJS 。

• 要跟後端 framework 結合的話，可以把 app 這個目錄改成 public 。但還需要對應改以下兩個部份：

  • bower.json 加入 "appPath": "public" 。
  • .bowerrc 及 karma.conf.js 中的 app/ 改成 public/ 。

• 儘量不要改 index.html 裡的註解，因為 Grunt 的 task 會用到它們來做管理 assets 。

• yo angular:route <route-name> --route=<path> 會自動幫你新增對應的 Controller / Route / View 。
• yo angular:directive <directive-name> 的 directive-name 要用 - (dash) 。

• grunt test 預設是用 Chrome 和 Jasmine 來執行測試，所以要先執行以下指令：

  npm install karma-chrome-launcher karma-jasmine --save-dev
  

• grunt build 後的所有檔案會放在 dist 目錄下，所以線上 Web 環境要把網站根目錄指到 dist 目錄，而不是 public 目錄。

接下來要想想看是不是能改用 Gulp 處理，我對 Grunt 已經不是那麼有愛了。

看到上面的文章收集了許多前端開發參考資訊，覺得非常實用，故將重點整理如下：

1. CSS Vocabulary
   可以瞭解 CSS 中的名詞實際對應的部份。
2. Liquidapsive
   介紹 Responsive / Adaptive / Liquid / Static 四種排版方式及其差異，網站本身即為實例。
3. Superhero.js
   這個網站收集非常多有關 JavaScript 的文件、簡報或影片！
4. HowToCoffeeScript.com
   把許多常用的 CoffeeScript 技巧整理成速查表。
5. The HTML Landscape
   介紹 WHATWG / W3C’s HTML5.0 / W3C’s HTML5.1 三種 HTML 規格的差異。
6. The Elements of HTML
   把 2.0 ~ 5.1 各個版本的 HTML 元素整理出來了，非常詳盡！
7. JavaScript Equality Table
   用二維表的形式來呈現 JavaScript 的 == / === / if 是如何比對值。
8. Web Accessibility Checklist
   列出專案如果要達成無障礙所需要注意的項目。
9. Static Web Apps — A Field Guide
   列出了常見的 Web Apps 開發注意事項或解決方案。
10. Learn regular expressions in about 55 minutes
    列出正規表達式學習的重點，並輔以範例供參考。
11. Open Web CSS Reference
    這個網站整理了 CSS 屬性與其進階特色的 W3C 連結。
12. CSS Values
    輸入 CSS 屬性後，可以看到它的屬性值參考、瀏覽器相容性及相關連結。
13. ES6features
    整理了 ECMAScript 6 的特色。
14. Relevant Spec Links
    列出許多有關前端技術的規格連結。
15. OverAPI.com
    幾乎把所有有關網站開發的語言或工具所使用的 API 都整理成速查表了。
16. JavaScript: The Right Way
    整理了所有有關 JavaScript 的開發相關資訊。
17. The HTML5 JavaScript API Index
    整理了 HTML5 在 JavaScript 的所有 API 。
18. Zeal
    類似 Mac 上的 Dash 參考文件整合軟體，是給 Linux / Windows 使用者。
19. The Ultimate Flexbox Cheat Sheet
    整理有關 CSS FlexBox 的教學。
20. jsCode
    可以自訂並產生 JavaScript Coding Guideline 的服務。

​http://www.screenr.com/gZN8

也就是在有動畫效果時，某些元素上的文字粗細會被改變；然而實際用 DevTools 去查看該元素 CSS 時，會發現文字粗細樣式並沒有任何變化。

後來找到這篇解法： ​Safari changing font weights when unrelated animations are running

依照這一篇的解釋，是因為新的 webkit 在將 HTML 交由 GPU 繪製時如果有動畫效果，就會造成 top 和 left 的偏移；而 webkit 預設使用 -web-font-smoothing: subpixel-antialiased 來繪製文字，卻不是每個元素都套用，因此就會造成這個問題。

連結提供的解法有兩種：

解法一：從該動畫元素往上找到最上面那個位置會動的元素，為它加上 position: relatvie 及 z-index ，如果不行就用解法二。

解法二：強制指定 html 的 -web-font-smoothing 為 antialiased 或 subpixel-antialiased ，讓整個頁面的元素都繼承同一種文字樣式設定。

後來我用解法二，在 CSS 開頭加了這段：

html {
  -webkit-font-smoothing: subpixel-antialiased;
}

問題就解決了。

其實鐵路站務人員是在確認那個號誌是否正確顯示，雖然用看的就可以，但他們會輔以動作來加強自己看到它的印象，這個動作稱為：指差確認。 (確認號誌是其中一項，可以看 Wiki 有更詳盡的說明。)

這個動作雖然較常見於危險性較高的行業，但它其實在軟體開發上，也以不同的形式存在著，那就是測試。

身為 Web 開發者，可能常會在修正一個自認只是影響不大的問題後，就直接讓程式上線；結果沒多久後就發現這個小修正影響到了其他地方，只好再趕緊針對這個修正再做修正。而良好且完整的測試可以減少出現這種問題的機會，但問題是我們常常會忘了要執行它。這件事要是發生在其他高危險性的職業 (我可沒說是台鐵) ，那麼後續的責任可就不是只有露出〇〇這麼簡單了。

軟體工程師的指差確認，就是養成隨手執行測試並確認結果的習慣；不論是什麼開發環境或編輯器，都應該試著把自動化測試放在開發流程裡，並且用最簡化的操作方式來讓自己能隨時執行它，以最清楚的呈現方式來讓自己能隨時看到它。雖然在軟體開發上還有其他方式可以來輔助我們做好這件事，像是 pre-commit hook 或是 Continuous Integration 等；但是讓自己也確實注意到測試的結果，將會加強我們自己對軟體承諾的力度，也有助於我們在開發上的專注力。

「渙散不論在什麼行業，都是效率的殺手。」

如果有「我好像有確認但我不確定」的狀況發生時，快讓自己養成用指差確認的習慣吧。