PHP Unit自動化單元測試技術研究

王莉軍

（渤海大學 大學計算機教研部，遼寧 錦州 121013）

一個函數、一個類編寫完成，到底能不能正確工作？怎么測試它？PHP單元測試是個好辦法，它提供了自動化測試的方法，使敏捷開發的自動化測試成為可能。

1 單元測試的前提條件（單元測試的基礎）

1）代碼具備基本可測試性。及要求被測試函數具備輸入輸出。（本測試方案未考慮無輸入輸出函數的測試）

2）被測函數盡可能分情況說明輸入輸出。及期望輸入及輸出和非期望輸入對應輸出。

3）被測還是應該有基本的函數說明，表明函數的功能[1]。

2 單元測試管理

1）對于某個系統，不同層的代碼放置于不同文件夾下。以talk為例，其有dataaccess層和logic層，那么其dataaccess層代碼放置于文件夾dataaccess之下。而單元測試文件的布局則和系統代碼布局一一對應。對于某個文件a.php，其對應的測試文件命名則為aTest.php。而對于a.php中某個函數method來說，其對應的測試函數命名應該為testMethod[2]。

2）每個測試函數應該包括一定的注釋。不依賴于dataprovider的情況。

/**

*@author****

*@note****

*@expect input**

*@expect output**

*@unexpect input**

*@unexpect output**

*/

依賴于dataprovider的情況：

/**

*@author**** /**

*@note**** *@expect 1，2，3

*@dataprovider** *@unexpect 4，5，6

*/ */

1）在測試根目錄下應該包含有各文件夾下文件測試覆蓋率統計文件夾。

2）單元測試代碼應該避免過多的依賴關系。盡量減少對外部環境依賴，減少對外部代碼具體實現依賴，減少對測試內部函數之間的依賴[3]。

3 單元測試編碼（通過場景展示）

場景一：一般簡單情況的函數測試

1）被測試class如下：

Class MyMathClass

{

/*

**add two given values，and return the sun

*/

Public function add（$a，$b）

{

Return$a+$b；

}

}

?>

2）測試 class如下：

Require_once ‘PHPUnit/Framework.php’；

Require_once ‘MyMathClass.php’；

/**

*Test class for MyMathClass.

*Generated by PHPUnit on 2011-03-31 at 13:11:05

*/

Class MyMathClassTest extends PHPUnit_Framework_Testcase

{

/**

*@var MyMathClass

*@access protected

*/

Protected$object；

/**

* Setsup the fixture，forexample，opens a network connection.

*This method is called before a test is executed.

*

*@access protected

*/

Protected function setup（）

{

$this->object–new MyMathClass；

}

/**

* Tears down the fixture，for example，closes a network connection.

*this method is called after a test is executed.

*

*@access protected

*/

Protected function tearDown（）

{ }

/**

*@todo ImpLement testAdd（）.

*/

Public function testAdd（）{

//Remove the following lines when you implement this test.

$this->assertEquales（3，$this->object->add（1，2））；

}

}

?>

簡單單元測試class里僅僅包含一個被測試的method的，而在生成的測試class里邊包含了除對應add函數的測試函數testAdd以外，還包含setUp和tearDown函數。其中setUp是在每個測試函數執行之前都會自動執行一遍，用來自動建立每個method的獨立測試上下文環境，通用tearDown在每個測試函數執行之后執行一遍，用來清除此method執行之中設定的上下文[4]。而testAdd則用來對add函數進行測試。testAdd函數中只包含一條語句，這條語句即假定通過調用add函數執行1加2，我們期望其返回的結果與3相等。如果相等，執行結果則通過，如果不相等則測試失敗，說明代碼并沒有完成我們想要的功能，如圖1所示。

圖1 測試結果Fig.1 Test execution results

場景二：針對數據庫增刪查改函數的測試

1）被測試函數如下：

/**

*Message的數據訪問

*/

Class DMessage extends Dataaccess{

/**

*單條消息（通過緩存）

*/

Public static function get（$message_id） {

$message=self==getCache（$message_id）；

If（!$message）{

$message=self==getByDb（$message_id）；

If（self==isTure（$message）） {

self==setCache（$message）；

}else{

Return$message；

}

}

Return$message；

}

2）測試函數如下：

Class DMessageTest extends CDbTestCase

{

Public$fixture=array（

‘message’=>’:tb_message’，

）；

/**

*Implement testGet（） {

*

*/

Public function testGet（） {

$message=$this->message[‘sample1’]

DMessage==deleteCache（$message[‘id’]）；

$ret=DMessage==get（$message[‘id’]）；

$this->assertEquals（$message[‘id’]， $ret[‘id’]）；

}

3）datafixture

Return array（

‘sample1’=>array（

‘id’=>1，

‘user_id’=>1，

‘content’=>’unit test’，

‘source’=>’unit test’，

‘lat’=>1，

‘lon’=>1，

Location’=>1，

‘forword_count’=>0，

‘reply_count’=>0，

‘pic_id’=>0，

‘pic_filename’=>’’，

‘pic_id_water’=>0，

‘pic_filename_water’=>’’，

‘created_time’=>’2011-03-21 11:21:59’，

‘last_forward’=>0

‘is_deleted’=>0，

‘fid’=>0，

‘is_safe’=>0’

‘media_json’=>’’

‘message_json’=>’’，

上面的DMessage class下的get函數是去獲取一條關于message的記錄。忽略此函數間的依賴性來說，如果在測試的時候，cache中不存在關于此message的記錄，則需要往數據庫中去取此條記錄，而在測試此函數的時刻，數據庫中是否存在需要查找的message記錄是無法確定的，所以會導致函數的上下文環境不確定，進而導致測試無法進行。或者在每次測試之前手動地去刪除或者添加記錄，在測試過程中還要防止其他人刪除此記錄[5]。在測試函數中出現了fixtrue變量，這個變量的作用就是在每個測試method執行之前清空數據庫中某張或者多張表里的數據，然后插入給定的數據，給定數據通過在fixture文件中設置，而fixture中文件命名規則為表名字.php。（例如數據中有一張表名字為tb_message，則fixture里有一個文件名字為tb_message.php，文件內容對應為一個數組，數組每個變量對應數據庫表中一條記錄）。通過使用fixture，能夠使單元測試在一個給定的上下文環境中進行[6]。

場景三：被測試的函數存在對其他函數調用

解決方案：1）使用phpunit自帶的mock或者stub方法2）使用 runkit中的 method_redifine 方法（）。

1）被測試class

Class LContactNsg

{

/**

*@param$userId

*@param$sendUserId

*@return unknown_type

*/

Public static function agree（$userId，$sendUserId）

{

If（DContactMsg==check（$userId，$sendUserId））

{

DContactMsg==delete（array（$userId，$sendUserId））；

DContactMsg==delete（array（$sendUserId， $userId））；

If （false!==DContacts==insert（array（$userId，$sendUserId）））

return true；

Else

return false；

}

return true；

}

}

2）測試 class

require_once’/home/work/htdocs/php/development/liuxiang/talk/dataaccess/DContactMsg.php’；

require_once’CsvFileIterator.php；

/**

*Test class for LContactMsg.

*Generated by PHPUnit on 2011-05-06 at 16:20:13.

*/

Class LContactMsgTest extend CTestCase

{

/**

*Implement testAgree（）.

*@dataaprovider agreeProvider

*/

Public function testAgree （$userId，$sendUserId，$expect，$re1，$re2，$re3）{

runkit_method_redefine （‘DContactMsg’，’check’，’’，

“$re1，

RUNKIT_ACC_PUBLIC）；

runkit_method_redefine（‘DContactMsg’，’delete’，’’，

“$re2，

RUNKIT_ACC_PUBLIC）；

runkit_method_redefine（‘DContactMsg’，’insert’，’’，

“$re3，

RUNKIT_ACC_PUBLIC）；

$result=LContactMsg==agree （$userId， $sendUserId，$expect，$re1，$re2，$re3）；

$this->assertEquals（$result，$expect）；

}

Public function agreeProvider（0

{ return array（

array （1，8，true，’return true；’，’ return true；’’return true；’）

）；

}

}

?>

由于單元測試關注點為當前測試函數是否能夠能正確地完成相應的任務，而不關注被此函數調用函數能否正確完成任務。而如果不對調用函數進行mock，當此函數測試失敗時，我們便無法立刻區分是當前被測試函數出現bug還是被被測函數調用函數出現bug。因此我們可以mock被被測函數調用的函數，讓其返回我們所期望的值，這樣就可以方便快捷地測試被測函數是否滿足要求[7]。此測試class中使用的是runkit函數庫中的runkit_method_redifine方法。而phpunit中也有相應的處理方法，及mock和stub。但是phpunit中的方法不能處理static方法調用，而runkit無此限制[8]。

4 結 論

自動化測試的目的是減少代碼的bug，一旦你開始習慣使用自動化測試，你將發現你的代碼的bug在減少，你的代碼的可信性在增加，有了可信的保證，你可以對你的代碼進行大膽的重構，取得事倍功半的效果[9]。

[1]吳高峽，王芙蓉.單元測試的自動化實踐[J].計算機與數字工程，2007（1）：15-17.WU Gao-xia，WANG Fu-rong.Unit test automation practices[J].Computer and Digital engineering，2007（1）:15-17.

[2]陳靜.單元測試在軟件開發過程中的作用[J].艦船電子對抗，2006（3）：25-28.CHEN Jing.Role of unit testing in software development[J].Warship EW.，2006（3）:25-28.

[3]陳站華.軟件單元測試[J].無線電通信技術，2003（5）：124-126.CHEN Zhan-hua.Software unit test[J].Radio Communications Technologies，2003（5）:124-126.

[4]侯鯤，林和平，楊威.設計模式在自動單元測試框架中的應用[J].計算機工程與應用，2004（31）：256-259.HOU Kun，LIN He-ping，YANG Wei.Application of design pattern in automated unit testing frameworks[J].Computer Engineering and Applications，2004（31）:256-259.

[5]林海，歐鋼，向為.軟件測試策略綜述[J].軟件導刊，2008（10）：165-168.LIN Hai，OU Gang，XIANG Wei.Overview of software testing strategies[J].Software DVD Guide，2008（10）:165-168.

[6]張巍，尹海波，孫立財.軟件的單元測試方法[J].光電技術應用，2006（2）：58-61.ZHANG Wei，YIN Hai-bo，SUN Li-cai.Software unit test method[J].Application of Opto-electronic Technology，2006（2）:58-61.

[7]王麗達.論軟件系統的測試[J].經濟研究導刊，2011（14）：82-85.WANG Li-da.On testing of software systems[J].Economic Research Guide Magazine，2011（14）:82-85.

[8]許學軍.軟件測試軟環境的構建與優化[J].中國民航飛行學院學報，2006（4）：36-38.XU Xue-jun.Soft environment construction and optimization of software testing[J].Journal of China Civil Aviation Flying College，2006（4）:36-38.

[9]王鵬，習媛媛，馬麗.單元測試在軟件質量保證中的應用研究[J].山西財經大學學報，2009（S2）：52-54.WANG Peng，XI Yuan-yuan，Ma Li.Study on the application of unit testing in software quality assurance[J].Journal of Shanxi University of Finance and Economics，2009（S2）:52-54.