国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

【持續集成你的項目】為你的項目創建自動化測試和代碼覆蓋率測試

Jeff / 2526人閱讀

摘要:單元測試中,代碼覆蓋率經常被用來衡量測試好壞的指標。執行的結果和導出的結果都可以在的下看到接下來就是把這些文件到上,就會自動構建,然后開始單元測試,并把測試結果中的代碼覆蓋率發送到。

本文以PHP項目作為例子
所需要擁有(準備)的:

Github賬號

一個項目

看著篇幅挺大的,難免有什么遺漏,如果文中有錯誤的地方,還請各位斧正!謝謝。
因為本來篇幅就大,所以就沒配圖了,如果有很多人反饋看不懂或者失敗了,我再后期補下圖。謝謝!

Travis-CI

項目為保證項目始終處于健康穩定的狀態,我們需要一個可以持續的自動的對貢獻的代碼進行自動化測試的服務。
Travis-CI就是在這樣的背景下于2011年開啟服務,到現在為止已經有超過300k個開源項目和235k的用戶在使用。

Travis-CI所做的工作就是自動在虛擬機中運行.travis.yml中設定的內容進行單元測試,生成并導出報告。

Composer

開源項目之間一般有著相互依賴的關系,比如項目A的一個組件依賴于另一個項目B。當這種依賴關系多了之后就需要一個管理依賴的工具。

Composer就是PHP的一個依賴管理工具。它允許你申明項目所依賴的代碼庫,并且會在你的項目中安裝他們。Composer中文

Packagist

Packagist is the main Composer repository. It aggregates public PHP packages installable with Composer.

這個網站是主要的Composer倉庫,通過Composer發布的項目,所儲存的倉庫就是這個網站,這也是Composer安裝依賴的下載來源。可以使用Github賬號登錄

登錄之后可以提交自己的項目,不過需要項目中有composer.json文件,這在之后進行介紹。

Coveralls

單元測試中,代碼覆蓋率經常被用來衡量測試好壞的指標。

所謂的代碼覆蓋率簡單的說就是在運行完測試用例之后,走過了多少句的代碼,比如說,你要測試的一個函數有100行,但是測試用例只走過了80行,所以這個測試用例的代碼覆蓋率就是80%

Coveralls就是一個根據單元測試導出的數據進行分析,展現代碼覆蓋率的一個工具。可以和很多的自動構建工具一起使用,本文以Travis-CI為例。

項目最終的目錄結構
/
├── src/
│?? └── ClassName.php
|── tests/
| ? ├── ClassNameTest/
| ? |   └── ClassNameTest.php
|?? └── Bootstrap.php
|── .coveralls.yml
|── .travis.yml
|── LICENSE
|── README.md
|── composer.json
|── example.php
└── phpunit.xml.dist

下面開始具體的配置方法。

Composer

如果想更深入的學習Composer可以查看官方文檔(地址在這一節最后)。一個重要的概念就是每一個項目都是一個包
所以我們首先需要在項目根目錄新建一個composer.json文件,其中的內容為(稍后我們再看其中的意思)

{
  "name": "jshadowman/package",
  "description": "this is a test package",
  "version": "0.0.1",
  "type": "library",
  "keywords": [ "database", "logging" ],
  "license": "MIT",
  "require": [
    "php": ">=5.4.0"
  ],
  "require-dev": [
    "satooshi/php-coveralls":"*",
    "phpunit/phpunit": "*"
  ],
  "autoload": {
    "files": [ "./src/ClassName.php" ]
  }
}

name: 這個字段顧名思義,包的名字,應該包含Verdor name(供應商)和Project Name(項目名)。值得注意的是這個字段的值應該都是小寫的,這和資源庫發布注冊有關。具體請參考 Packagist

description: 這個字段應該是這個項目的一個簡短的簡介。一行即可

version: 項目的版本,并不是必須的,而且建議忽略,具體請參考 Version 中文

type: 項目的類型,可選的值有library project metapackage composer-plugin 具體請參考 Type 中文

keywords: 用于在被搜索時的關鍵字,可以是一個數組 Keywords 中文

license: 項目發布所使用的開源協議,可選的值請參考 License 中文

require: 這表示項目所依賴的軟件包列表,除非這些依賴被滿足,否則不會完成安裝。Require 中文

require: 我們的項目依賴于平臺軟件包,也就是PHP,PHP的擴展包和一些系統類庫。所以我們在require之中添加了對PHP的依賴,如果有依賴于其他的包,可以按照這種格式填寫。具體請參考 Platform-packages 中文

require-dev: 這個字段列出的依賴只有在測試和開發的時候才會安裝,屬于額外的依賴。具體請參考 Require-dev 中文

require & require-dev: 這兩個字段之下的列表項應該是包名到版本的映射,其中版本有很多種寫法,可以根據需求過濾。具體請參考 Package-Links 中文

autoload: 表示的是autoloader的自動加載映射。具體請參考 Autoload 中文

autoload: 其中的映射關系設計到PHP命名空間(Name Space)的一些知識,具體請參考 PSR-0 - PSR-4 - PSR0-4_Github

composer.json中有很多可選的字段和值,編寫的規范可以參考Document,中文文檔

Coveralls

在項目的根目錄新建.coveralls.yml文件,其中的內容為

coverage_clover: build/logs/clover.xml
json_path: build/logs/coveralls-upload.json

coverage_clover: 表示使用指定目錄的Clover XML格式的XML文件,默認指向build/logs/clover.xml

json_path: 用來指定將被上傳到Coveralls網站的json文件,默認指向build/logs/coveralls-upload.json

值得注意的是舊版本所使用的src_dir已經在1.0.0版本中被移除了,所以請注意不要使用這個選項
Removed src_dir from CoverallsConfiguration

還有其他的配置選項請參考Github - satooshi/php-coveralls

接下來在Coveralls網站中添加倉庫:

進入 Coveralls 網站 https://coveralls.io/

點擊右上角的 SIGN IN,在接下來的頁面中選擇GITHUB SIGN IN,然后使用自己的Github賬號授權登錄

如果你沒使用過Coveralls的話,登錄成功的界面應該是讓你添加一個代碼倉庫

ADD REPO標題下列表中將你的項目從OFF撥到ON

接下來配置PHPunit單元測試。

PHPUnit

在你的項目根目錄新建phpunit.xml.dist文件,其實這個文件也不一定要新建在根目錄,主要記得修改文件內容中的路徑就行,不過最好就是根目錄和tests文件夾內了。

phpunit.xml.dist文件的內容為


    
        
            ./tests
        
    
    
        
            ./src
            
                ./vendor
                ./tests
                ./example.php
            
        
    
    
        
        
    

根元素中的屬性

bootstrap 表示在測試運行前先運行一個 "Bootstrap" PHP文件,一般用于配合Composer中的自動載入,確保不會發生找不到類的情況

colors 表示是否使用彩色輸出

convertErrorsToExceptions PHPUnit 將會安插一個錯誤處理函數來將錯誤轉換為異常,設置為 false 則表示禁用

convertNoticesToExceptions 此選項設置為 true 時,由 convertErrorsToExceptions 安插的錯誤處理函數會將 E_NOTICE、E_USER_NOTICE、E_STRICT 錯誤轉換為異常。

convertWarningsToExceptions此選項設置為 true 時,由 convertErrorsToExceptions 安插的錯誤處理函數會將 E_WARNING 或 E_USER_WARNING 錯誤轉換為異常。

帶有一個或多個 子元素的 元素用于多組的測試套件

顧名思義,過濾器,對目錄下的文件或文件夾進行過濾

下的 表示白名單,即需要的部分

下的 顧名思義,即需要的目錄

下的 這是需要排除的部分,底下的排除項目看標簽名就知道了,可以排除目錄或者單個文件

最后的部分就是日志紀錄的內容了。

表示導出coverage-clover格式的文件,導出文件名為build/logs/clover.xml

表示將日志直接輸出到標準輸出,即終端上。

完整的XML格式,內容可以參考 XML配置文件

需要注意的是在根元素中的屬性并不是所有都在那個頁面介紹的,還有一部分在命令行選項之中,所以如果在附錄C找不到,那就去命令行選項(注意根元素屬性在命令行選項中是以-分隔的)那一節找找,肯定有的。

Travis-CI

使用Github賬號登錄Travis-CI Sign Up

點擊自己的頭像進行個人資料界面,在下面你的項目中,點擊你所需要自動構建的項目前的按鈕,這個按鈕就會變成綠色的勾

在點擊到自己的用戶信息界面之后,在你的Repo上面會有一個簡單的使用介紹,開啟Travis-CI是很簡單的。

在你的項目根目錄新建.travis.yml文件,其中的內容為

language: php

php:
  - "5.4"
  - "5.5"
  - "5.6"
  - "7.0"

before_script:
  - composer install --prefer-dist --dev --no-interaction

script:
  - mkdir -p build/logs
  - phpunit -c phpunit.xml.dist --coverage-clover build/logs/clover.xml

after_script:
  - travis_retry php vendor/bin/coveralls -v

language: 顧名思義,這就是你項目所用的語言,所支持的語言和格式可以查閱 Document,配置PHP

php: 這個底下是自動構建所使用的環境。注意,有固定的格式

before_script: 顧名思義,在正式script之前運行的腳本(Shell)命令

script: 開始測試所用的命令

after_script: 在測試結束之后運行的命令,比如用于導出結果到COVERALLS

其中所用到命令介紹

開始測試之前需要做的準備工作,即安裝項目需要的依賴包。
composer install --prefer-dist --dev --no-interaction

這句命令的作用是根據composer.json所描述的依賴關系進行依賴的安裝,具體請參考 Install 中文

--prefer-dist: composer 將盡可能的從 dist 獲取依賴的項目,這將大幅度的加快在 build servers 上的安裝

--dev: 安裝 require-dev 字段中列出的包

--no-interaction: 不要詢問任何交互問題。因為是自動進行依賴安裝的,我們不能手動控制,所以發生任何需要交互的問題,我們都是處理不了的

準備工作做好之后,開始正式的測試工作,首先當然需要先新建一個存放日志的目錄
mkdir -p build/logs

這句命令會讓系統創建一個連續的目錄,如果父目錄不存在就先創建父目錄

開始進行單元測試并導出代碼覆蓋率報告
phpunit -c phpunit.xml.dist --coverage-clover build/logs/clover.xml

這句命令是運行phpunit進行單元測試,具體請參考 PHPUnit - 命令行選項

-c phpunit.xml.dist: 從指定的文件中讀取配置信息,這里的配置文件是phpunit.xml.dist

--coverage-clover build/logs/clover.xml:生成并導出Clover XML格式的代碼覆蓋率報告

測試完之后接下來就是導出報告到Coveralls了
travis_retry php vendor/bin/coveralls -v

這句命令是其實是php vendor/bin/coveralls -v,前面的travis_retry的作用是檢查后面命令的返回值,如果不是0(返回值為0表示正常結束),那就重復執行3次,如果3次都不為0,那就報錯。

php vendor/bin/coveralls -v:

這句命令是使用PHP執行vendor/bin/下的coveralls這個文件,-v表示verbose,即顯示詳細的報告。
這個命令執行之后就可以在Coveralls這個網站中看到詳細的數據了。

phpunit執行的結果和coveralls導出的結果都可以在Travis-CIBuild Jobs下看到

git push

接下來就是把這些文件push到Github上,Travis-CI就會自動構建,然后開始單元測試,并把測試結果中的代碼覆蓋率發送到Coveralls。如此,一套流程就結束了。

展示

辛辛苦苦大半天,就是為了展示自己的成績啊。
所以我們看到的別人家項目地下這么漂亮的圖標我們也要有啊。

README.md文件中添加(注意將以下 Github_ID 替換為自己的 Github-ID,將 Repo_Name 替換為你的項目名字。沒有尖括號哦~還有注意區分大小寫哦~如果還需要改分支(branch)的話,看到鏈接你應該也懂吧?我相信你! )

[![Build Status](https://travis-ci.org//.svg?branch=master)](https://travis-ci.org//)
[![Coverage Status](https://coveralls.io/repos/github///badge.svg?branch=master)](https://coveralls.io/github//?branch=master)

其實這些markdown語句可以直接復制的

Travis-CI: Build圖標可以在Travis-CI網站中自己項目名的右邊有一個 build:**** 的圖標,直接點擊這個圖標,將Image URL改成Makedown就可以看到啦

Coveralls: 也是進入自己Repo的詳細信息中,中間是LATEST BUILDS信息,在最右邊有一個README BADGE,底下那個圖標右邊有個按鈕Embed ?,點擊復制Markdown的語句即可。

Packagist(可選)

在覺得自己的項目開發的差不多時,我們就可在在Packagist上發布自己的包啦,發布之后,就可以被別人的項目通過Composer所依賴~

可以使用Github賬號登錄,或者自己注冊個賬號登錄,在右上角Sign In選擇是注冊還是使用Github賬號登錄

注冊完之后,可以在右上方Submit中提交一個包,點擊Submit按鈕 - Submit

接下來會讓你輸入Repository URL,直接輸入git://github.com//

Packagit會在后臺clone你的項目,并且檢查項目中的composer.json文件,第一個要檢查的就是包的名字,如果包名中有大寫的字母,Packagit就會報一個包名不應該有大寫字母的錯誤,所以,這就是上文所說包名最好是小寫的來由。

提交之后就可以看到自己的這個包的一些信息了,比如被下載了多少次,被安裝了多少次。

回到Github,打開代碼倉庫的Settings -> Webhooks & services,然后在Services右邊有個Add Service的按鈕,點擊輸入查找Packagit

之后會讓你輸入用戶名和Token,這些信息都在你的Packagit主頁中 個人主頁

個人主頁有個Your API Token的按鈕,按下按鈕,就可以看到自己的API TOKEN了,注意保密哦

其中packagist海油4個小圖標,記得替換 PACKAGIST_IDPACKAGE_NAME 哦,不是 Github_IDRepo_Name

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/21562.html

相關文章

  • 你的GitHub項目添加持續集成Travis CI

    摘要:為你的項目添加持續集成本篇文章接上篇基于發布包的流程,繼續為項目添加持續集成提供的是持續集成服務。它綁定上的項目,只要有新代碼更新,它就會自動抓取。 為你的GitHub項目添加持續集成Travis CI 本篇文章接上篇 《基于typescript發布npm包的流程》,繼續為項目添加持續集成 Travis: Travis CI 提供的是持續集成服務。它綁定 GitHub 上的項目,只...

    kyanag 評論0 收藏0
  • 看吧,這就是現代化 PHP 該有的樣子

    摘要:這大概是我沒有及早使用,或多數開發者流連現狀造成的。它就是,一個的框架。行為驅動開發是來自測試驅動開發的開發過程。簡單的說,它就是經常可能一天幾次將小塊代碼整合進基礎代碼當中的行為。 showImg(https://segmentfault.com/img/remote/1460000013769815); 這是一篇社區協同翻譯的文章,已完成翻譯,更多信息請點擊?協同翻譯介紹?。 文章...

    Tangpj 評論0 收藏0
  • 一個靠譜的前端開源項目需要什么?

    摘要:一個靠譜的應該包含以下幾部分言簡意賅的項目介紹你的項目解決了什么核心問題,有哪些令人心動的特性。除了在中提到遵循的開源協議外,一個靠譜的開源項目還會將該開源協議的內容文檔放在自己的項目下方。 0. 前言 寫前端代碼一段時間之后,你可能會萌生做一個開源項目的想法,一方面將自己的好點子分享出去讓更多的人受益,另一方面也可以在社區貢獻的環境下學到更多的東西從而快速成長。但是開源項目也有開源項...

    hiyayiji 評論0 收藏0
  • 一個靠譜的前端開源項目需要什么?

    摘要:一個靠譜的應該包含以下幾部分言簡意賅的項目介紹你的項目解決了什么核心問題,有哪些令人心動的特性。除了在中提到遵循的開源協議外,一個靠譜的開源項目還會將該開源協議的內容文檔放在自己的項目下方。 0. 前言 寫前端代碼一段時間之后,你可能會萌生做一個開源項目的想法,一方面將自己的好點子分享出去讓更多的人受益,另一方面也可以在社區貢獻的環境下學到更多的東西從而快速成長。但是開源項目也有開源項...

    DesGemini 評論0 收藏0

發表評論

0條評論

Jeff

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<