摘要：創建帳號提供的是持續集成服務，簡稱。在這里引入的原因是我們的項目需要使用服務進行持續集成和測試，當然你也可以替換成別的單元測試工具。創建單元測試用例是單元測試類庫家族中的一員，使用的一個主要目的是為我們的模塊創建單元測試用例。

本文首發于 Travis CI 持續集成服務構建 Composer 類庫簡明教程，轉載請注明出處！

在項目開發過程中，編碼工作只是軟件開發整個過程中的一小部分環節，更多的我們需要去構建和測試我們的項目，以確保項目的健壯和穩定性。

這篇文章將帶領大家學習如何使用 Travis CI 持續集成服務和 Composer 中國 包管理工具，來構建一個持續集成的 PHP 類庫。

進入正題之前，需要大家對以下幾個工具已經有了初步的了解和使用經驗：

Git: Git 是分布式版本控制系統；

Composer：Composer 是 PHP 項目的依賴管理工具，用于管理項目中的 packagies 和 libraries；

GitHub：是一個用于使用 Git 版本控制系統項目的共享虛擬主機服務，可以免費托管公開的源代碼倉庫。

Packagist：主要提供 Composer 包發布和索引，默認 Composer 從 Packagist 獲取資源。

如果沒有的話，最好還是先了解一下如何使用它們，下面讓我們簡單介紹一下創建相關服務賬號的方法。

GitHub 是一個用于使用 Git 版本控制系統項目的共享虛擬主機服務，可以免費托管公開的源代碼倉庫。

本教程的基礎就是基于 Git 和 GitHub 服務，所以需要我們創建 GitHub 帳號，并且 GitHub 官方提供 Packagist、Travis CI 的鉤子服務。

當我們將本地的項目推送（push）到 Github 時，Packagist 和 TravisCI 服務會觸發相關的鉤子服務，去獲取最新的代碼。

如果沒有賬號的話趕緊去 注冊 GitHub 帳號 吧！

Packagist 是 Composer 默認的包管理服務倉庫，我們使用 Composer 安裝（install）或引入（require）一個依賴包時，默認是從這里拉取依賴包的代碼。

所以，開發 Composer 類庫，需要使用我們的 Github 帳號 授權 并登錄 Packagist 網站。

Travis CI 提供的是持續集成服務（Continuous Integration，簡稱 CI）。它綁定 Github 上面的項目，只要有新的代碼，就會自動抓取，然后提供一個運行環境，執行測試，完成自動化構建，它還能將項目部署到我們的應用服務器。這個教程主要講解使用這個服務的測試和自動化構建功能。

在開始前讓我們先完成以下準備工作：

首先，訪問官方網站 Travis CI 使用 Github 授權登錄。

然后，當授權登錄成功后，點擊右上角用戶頭像，這樣 Travis CI 會獲取到 Github 上你所有的版本庫信息。

最后，選擇你需要使用 TravisCI 服務幫你執行測試和構建的倉庫，點擊開啟按鈕。開啟成功后，任何 GitHub 提交代碼操作，都會觸發 TravisCI 的鉤子服務，然后執行測試和構建處理。

在完成以上帳號注冊流程后，我們就可以進入到今天的正題，使用「使用 Travis CI 持續集成服務構建 Composer 類庫」。

完成帳號創建及授權相關準備工作后，現在讓我們就可以開始創建自己的 Composer 類庫了。

第一步需要到 GitHub 網站點擊站點右上角加號（?）創建一個新的項目倉庫，這里我創建了一個名為 travis-composer-tutorial。

默認的 GitHub 會給我們創建一個空的項目目錄，當然如果在創建時你選擇了需要創建 .gitignore、 開源協議和 readme 文件時，Github 還會給我們同時創建這些說明及配置文件。

緊接著，進入到我們的本地的工作目錄下，執行 git clone 命令將 GitHub 中的項目克隆到本地：

cd your_workspace_directory

git clone https://github.com/huliuqing/travis-composer-tutorial.git

請講自己的工作目錄及版本庫的 URL 地址替換掉。

初始化的目的是為我們新建的 travis-composer-tutorial 項目創建一個 composer.json 元數據文件。創建這個 JSON 配置文件有兩種方式：

手動創建這個 composer.json 文件，文件格式可以參考 庫 文檔；

通過 composer init 命令行工具，采用交互式命令創建。

// 在 travis-composer-tutorial 項目根目錄執行下面的命令

cd travis-composer-tutorial
composer init

引導初始化時需要我們創建以下幾個初始配置選項：

Package name: 包的名稱，我的是 phpzendo/travis-composer-tutorial；

Description []: 包的描述；

Author: 包的作者；

Package Type (e.g. library, project, metapackage, composer-plugin) []: 你開發的類庫類型；

Minimum Stability: minimum-stability 字段的值；

License: 采用的 開源協議；

require: 需要依賴的其它包，必須要有一個版本約束。并且應該遵循 foo/bar:1.0.0 這樣的格式。

下面是我初始化 Composer 項目的交互截圖，有一點需要說明由于當時網絡原因并沒有在初始化時添加依賴的其它包，后續我們可以使用 composer require 引入 PHPUnit 依賴：

通過 composer require 命令引入 PHPUnit 單元測試測試工具創建依賴。

composer require phpunit/phpunit

在這里引入 PHPUnit 的原因是我們的項目需要使用 Travis CI 服務進行持續集成和測試，當然你也可以替換成別的單元測試工具。

到這里，基本上我們就完成了一個創建初始 Composer 類庫的功能。接下來，我們將進入到項目的編碼階段。

完成基本的注冊和初始化工作后，才是進行項目編碼階段，在項目根目錄下創建 src 文件夾。

項目的所有源碼都會放置到 src 目錄下，并采用 PSR4 自動加載規范來定義文件結構。

PSR 是 PHP Standard Recommendations 的簡寫，由 PHP FIG 組織制定的 PHP 規范，是 PHP 開發的實踐標準。

這里我們需要使用 PSR4 規范是最新的「自動加載」規范，它的功能是讓 Composer 能夠正確查找并加載我們項目的源文件。

使用 PSR4 規范定義文件的目錄結構遵循以下原則：

()*

更多有關 PSR4 規范說明及使用可以查看 說明。

現在讓我們來編寫項目的首個模塊吧。

作為教程，這里我們假設需要創建一個 Dumper 類用于替代 php 內置的 var_dump 輸出功能。

到 src 目錄下創建子目錄 Dumper，同時創建 Dumper/Dumper.php 類文件。

 * @method mixed dump($expression, $title = null)
 * @license MIT
 */
class Dumper
{
    /**
     * 打印變量的相關信息
     *
     * @param mixed $expression
     * @param string|null $title
     * @return void
     */
    public function dump($expression, $title = null)
    {
        echo ($title ?: "調試：") . "
";
        var_dump($expression);
        echo "
";
    }
}

編寫完成我們的模塊后，需要將項目目錄配置到 composer.json 文件的 autoload 元數據中。

autoload 配置功能是定義 composer 自動加載與項目模塊的映射關系，定義后 composer 才能正確查找項目模塊自動引入類文件。

有關 autoload 使用說明可直接查看文檔。

確認項目的命名空間。

我們模塊的命名空間為 PhpZendoDumperDumper。

當前命名空間前綴為 PhpZendo 指向的是 src 目錄，意味著 composer 自動加載會查找 src/Dumper/Dumper.php 文件并引入（require）。

將命名空間及文件引入關系添加到 autoload 配置

打開 *composer.json 文件并添加如下配置：

    "autoload": {
        "psr-4": {
            "PhpZendo": "src/"
        }
    }

更新 composer 依賴。

執行如下命令更新自動加載依賴關系：

composer dump-autoload

到這里我們基本上已經完成了開發一個簡單的 composer 類庫，現在我們可以將項目推送到 GitHub。

但是在推送之前，我們需要到 Packagist 官網配置 travis-composer-tutorial 項目的鉤子服務。

將項目提交到 GitHub 遠程倉庫。

首先，確定是否有 .gitignore 文件，并確保 vendor 等目錄不會添加到版本控制中。

我的 .gitignore 文件實在創建 GitHub 時自動創建的：

composer.phar
/vendor/

# Commit your application"s lock file https://getcomposer.org/doc/01-basic-usage.md#commit-your-composer-lock-file-to-version-control
# You may choose to ignore a library lock file http://getcomposer.org/doc/02-libraries.md#lock-file
# composer.lock

推送項目到 GitHub。

git add *
git commit -m "Create travis and composer tutorial."
git push origin master

進入 Packagist 官網，點擊網頁右上角 Submit 按鈕添加 GitHub 代碼倉庫地址。

進入頁面后將 https://github.com/huliuqing/... 配置到 Submit package 表單，提交即可。

添加完成后我們的 GitHub 項目即添加到了 Packagist。

不過此時，我們的項目推送還不會自動在 Packagist 中完成任何代碼推送的更新操作，而需要我們手動的去執行 update 操作才行，原因是當前還沒有配置 GitHub 的鉤子服務。

如何配置鉤子服務，可以到 說明文檔 去深入了解一下。

在這一小節我們深入了解了如何創建 Github 版本庫，使用 Composer 命令行工具初始化本地類庫元數據信息；并且學習了如何定義項目自動加載配置和將 GitHub 版本庫關聯到 Packagist 站點。

下一節我們將講解本文另外一個主題，使用 Travis CI 服務構建持續構建和測試項目。

Travis CI 提供一個運行環境，然后執行測試，完成構建，甚至還能將我們的項目部署到應用服務器。

要知道我們在編寫軟件時，編碼僅僅是軟件開發過程中一小部分工作內容；一個可靠的項目還需要對其進行測試，使用 Travis CI 這類持續構建服務，可以簡化測試工作并保證項目的質量。

這一節將學習持續構建相關知識。

PHPUnit 是 xUnit 單元測試類庫家族中的一員，使用 PHPUnit 的一個主要目的是為我們的模塊創建單元測試用例。

在項目中，究竟何時才需要使用單元測試技術呢？

一個很簡單的判斷標準就是，當你想在項目中使用類似 var_dump 函數打印輸出內容時，一個更好的方式就是將輸出替換成單元測試。

讓我們在項目的根目錄下創建 tests 文件夾，之后我們所有的測試用例都會放置到這個目錄中。

接下來需要編寫 PHPUnit 測試用例，如何編寫一個簡單的測試用里遵循以下規則：

針對類 Class 的測試寫在類 ClassTest中；
ClassTest（通常）繼承自 PHPUnitFrameworkTestCase；
測試都是命名為 test* 的公用方法。

更詳細內容可以查看 PHPUnit 中文網 文檔說明。

所以這里我們創建一個 DumperTest.php 單元測試用例，并將這個測試用例創建在 tests/unit/DumperTest.php 路徑下：

 */
class DumperTest extends TestCase
{
    /**
     * 測試 Dumper 類實例化
     *
     * @return void
     */
    public function testDumper()
    {
        $dumper = new PhpZendoDumperDumper();

        $this->assertInstanceOf(PhpZendoDumperDumper::class, $dumper);
    }
}

這個測試用例主要用于檢測是否成功創建 Dumper 類。

完成測試用例編碼工作后，我們需要驗證測試是否通過。之前，我們的項目已經引入了 phpunit 依賴，所以這里我們可以通過下面的命令去執行測試腳本：

./vendor/bin/phpunit UnitTest ./tests/Unit/DumperTest.php

以下是執行結果：

有關 PHPUnit 命令行工具可以查看 命令行測試執行器 相關文檔。

雖然，我們現在能夠成功執行測試腳本，但是如果我們的測試用例有多個的話，這樣一個一個寫出每個測試文件似乎有點傻乎乎。

有沒有好的解決方案可以將所有 tests/unit 目錄下的測試文件都執行測試呢？

接下來會交大家如何編寫 PHPUnit 測試 XML 配置文件。

很多時候我們的測試腳本并非只有一個測試文件，而是會有許多的測試用例，這種情況下需要使用 XML 配置文件 來幫助我們的 PHPunit 找到所有這些測試文件路徑。

下面是我編寫的 phpunit.xml 配置文件信息：

    
        
            tests/Unit
        
    

其中我們需要重點關注以下幾個屬性功能：

配置文件包含一個 屬性，作用是用于配置 PHPUnit 的核心功能，其中 bootstrap 屬性用于設置自動加載文件路徑；

phpunit 包含一個或多個 ，作用是用于將測試套件及測試用例組合出新的測試套件；

用于配置測試用例目錄。

隨后，我們可以通過下面的 phpunit 命令行工具從 XML 文件中讀取配置并執行測試：

./vendor/bin/phpunit -c phpunit.xml

到這里說明我們的項目進行的非常順利，接下來就是需要到 Travis CI 配置 GitHub 項目的鉤子服務，并執行自動化測試。

如果測試一切順利的話我們就可以進行下一步，到 Travis CI 官網去開啟 travis-composer-tutorial （這里請開啟自己的項目）項目的鉤子服務，如何開啟可以到「創建 TravisCI 帳號」以及查看。

配置完成后可以看到看到 Travis CI 網站會獲取到我們的項目

Travis 服務提供多種編程語言的自動化測試支持，所有這里我們需要編寫 PHP 語言的測試配置。

Travis CI 配置文件使用 YAML 語言編寫，配置文件名為 .travis.yml。有關配置的具體細節可以到 Building a PHP project 去了解。

下面介紹我們的教程需要完成的一些配置信息：

language: php

php:
  - 7.1
  - 7.2

before_script:
  - composer install

script: ./vendor/bin/phpunit -c phpunit.xml

language 和 php： language 用于配置項目采用的編程語言； php 用于指出當項目使用 PHP 開發時選擇使用的 PHP 版本，這里我們使用 7.1 和 7.2 版本；

before_script: 用于在執行 script 腳本前，需要執行相關操作，我們這里去執行 composer install 操作安裝相關依賴；

script：用于配置我們需要執行的腳本，Travis CI 默認會使用 PHPUnit 作為單元測試工具，并運行 ./vendor/bin/phpunit -c phpunit.xml 進行單元測試。

在我們的配置中，可以將 script 配置簡寫成：./vendor/bin/phpunit。

git add *
git commit -m "Support travis ci and phpunit test."
git push origin master

推送到 GitHub 會觸發 Travis CI 的鉤子服務，并在 Travis CI 執行自動化測試和構建服務。

下面是 Travis CI 自動構建結果：

以上就是今天的主要內容，希望對大家有所幫助。

持續集成服務 Travis CI 教程

Composer 入門

使用 GitHub、Composer、Packagist 管理公開的 PHP 包（Step By Step）

Git 教程

TravisCI 文檔

如何簡單入門使用 Travis-CI 持續集成

學習開發自己的 Composer 包，并使用 GitHub 實時更新到 Packagist

YAML 語言教程