概述
在autofunc測試目錄下，建立conf、data、lib三個目錄，分別用於儲存配置資訊、資料檔案和lib庫，測試用例直接放在autofunc下。
a 方案
直接在test_object_put_get.php中require config.php和util.php，如下：
require_once 'conf/config.php';
require_once 'lib/util.php';
似乎很簡單,但這裡卻有兩個問題,phpunit的測試用例,是以class繼承phpunit_framework_testcase類的方式來組織的，這樣在testcase中就無法訪問config.php的變數列表，或許你會說，這個很好解決呀，直接的testcase的class中指定config.php的變數名為global型別即可，如下：
弊端1：config.php中有幾個配置，testcase中就需要global幾個，不免太手工了。
弊端2：util.php中function無法通過global方式宣告，在testcase中也就無法訪問到。
b 方案
鑑於a 方案的侷限性，我提出了物件導向的方式，來實現配置資訊、測試用例、lib庫有效的隔離。b 方案最突出的地方在於引入了繼承的概念，容我一一道來。
config.php
測試用例中總有一些常量會被反覆使用到，使用配置檔案的方式是所有測試人員的共識，在這裡，我做了乙個小小改善，將config資訊包裝為類的方式，以便於在lib庫的類中使用到，如下：
class config
util.php
編寫測試用例時，總會有一些邏輯處理片段反覆的出現，這造成了測試**的大量冗餘，也加大了維護成功，將這些邏輯處理封裝為乙個個函式是第乙個步，之後將通用的函式抽取為lib庫的形式，而那些函式適合抽取為lib庫。根據經驗我列舉幾個lib的共有特性：
1.與測試用例邏輯無關
2.完成單一職責
3.可被其他用例共用
如果滿足這三個條件，那這個函式就可以抽取為lib庫，如下文的signature簽名函式。
在實際專案中，我抽取了部分函式為lib庫，並將lib庫也封裝為類的形式，同時繼承於class config，如下：
require_once 'conf/config.php';
class util extends config
if($this->time != "")
$sign = "?sign=$this->sign_flag:$this->access_key";
return $sign;}}
注意：這裡util類繼承於config類，也就繼承了config類中的所有成員變數，故在util類中可以直接通過$this指標直接訪問到配置資訊。
test cases
testcases中通過在setup()函式中new乙個util物件，這樣就可以輕鬆使用lib庫中所有方法了，如下：
require_once 'phpunit/framework.php';
require_once 'lib/util.php';
class objectputget extends phpunit_framework_testcase
public function testnormal()
}這裡testcases中有乙個protect的成員變數$util，並在setup()中初始化，這樣在每個testcase中都可以使用$this->util來訪問util類中的所有方法和變數了。
問題：測試中可能遇到這樣的問題，lib庫的function依賴於config中的配置，在測試用例中呼叫function時，又希望能用不同的引數。
解決：按照gtest的測試經驗，需要為function提供額外的引數，供傳入不同的值。既然使用物件導向了，這裡就簡單了，只需要通過例項化的lib庫呼叫$this->util->配置項，直接更改配置項資訊。如果希望封裝好點，可以設定get、set方法分別用於配置項的get和set。
資料驅動
將測試資料儲存到data/目錄下的相應檔案中，通過php unit的dataprovider機制與測試**結合，將測試資料與用例邏輯解耦合，增加case只需要相應增減資料檔案，不需要變更用例邏輯，降低維護成本，提高可擴充套件性。
/*** dataprovider for testobjectfiletype
*/public function filetype()
/*** 檔案，檔案型別為txt word excel pdf *** mkv rar
* @dataprovider filetype
*/public function testobjectfiletype($filetype, $object_name)
這樣組織後，測試用例、配置資訊、資料檔案以及lib庫就解耦了，不管修改哪部分，都可以直接找到並修改，不用擔心會對其他case造成什麼影響。
a. 編寫測試用例，在測試用例根目錄下找到對應測試檔案，增減相應的case邏輯即可，並且可以在測試用例中輕鬆呼叫lib庫，動態修改配置資訊。
b. 修改資料檔案？兩步即可，在data目錄下增減資料檔案，修改對應測試用例的資料驅動資訊。
c. 在conf目錄中修改配置資訊，由於配置資訊是全域性的，修改已有配置資訊需要慎重。
d. lib庫與conf一樣是全域性可見的，修改已有function需要考量對其他case有沒有影響。
總結
不僅僅rd的**需要可擴充套件性，qa的測試**同樣也需要。
測試也需要設計。
【 【
PHPUnit 組織測試
首先是目錄結構 源資料夾為 src 測試資料夾為 tests user.php class errorcode class user public function isempty catch exception e return welcome this name 對應的單元測試檔案 userte...
PHPunit學習與實踐 二
phpunit frameworkd testcase的斷言方法 異常的測試 可以測試類的方法是否有對某些情況丟擲異常 public function testsetgoods longname 上例如果在商品名稱過長未丟擲異常時,測試時會顯示錯誤 2 baogoodstest testsetgoo...
PHPUnit單元測試
單元測試 phpunit 定義乙個用來被測試的類remoteconnect author json class remoteconnect fp fsockopen servername,80 return fp?true false public function returnsampleobje...