數(shù)據(jù)庫測試的難點(diǎn)

數(shù)據(jù)庫測試的難點(diǎn)

為什么所有單元測試的范例都不包含數(shù)據(jù)庫交互？這里有個(gè)很好的理由：這類測試的建立和維護(hù)都很復(fù)雜。對(duì)數(shù)據(jù)庫進(jìn)行測試時(shí)，需要考慮以下這些變數(shù)：

• 數(shù)據(jù)庫和表

• 向表中插入測試所需要的行

• 測試運(yùn)行完畢后驗(yàn)證數(shù)據(jù)庫的狀態(tài)

• 每個(gè)新測試都要清理數(shù)據(jù)庫

許多數(shù)據(jù)庫 API，比如 PDO、MySQLi 或者 OCI8，都十分繁瑣且書寫起來十分冗長，因此，手工進(jìn)行這些步驟絕對(duì)是噩夢。

測試代碼應(yīng)當(dāng)盡可能簡短精確，這有若干原因：

• 你不希望因?yàn)樯a(chǎn)代碼的小變更而需要對(duì)測試代碼進(jìn)行數(shù)量可觀的修改。

• 你希望在哪怕好幾個(gè)月以后也能輕松地閱讀并理解測試代碼。

另外，必須認(rèn)識(shí)到，對(duì)于代碼而言，本質(zhì)上來說數(shù)據(jù)庫是全局輸入變量。測試套件中的兩個(gè)不同的測試可能是運(yùn)行在同一個(gè)數(shù)據(jù)庫上的，并且可能把數(shù)據(jù)重用好多次。一個(gè)測試中出現(xiàn)的失敗很容易影響到后繼測試的結(jié)果，從而讓整個(gè)測試過程變得非常艱難。前面提到的清理步驟對(duì)于解決“數(shù)據(jù)庫是全局輸入”的問題是非常重要的。

DbUnit 以一種優(yōu)雅的方式來幫助簡化數(shù)據(jù)庫測試中的所有這些問題。

PHPUnit 無法幫你解決的問題是，相對(duì)于不使用數(shù)據(jù)的測試而言，數(shù)據(jù)庫測試是非常慢的。隨著數(shù)據(jù)庫交互規(guī)模的增大，運(yùn)行測試可能需要耗費(fèi)可觀的時(shí)間。然而，只要保持每個(gè)測試所使用的數(shù)據(jù)量較小并且盡可能用非數(shù)據(jù)庫測試來對(duì)代碼進(jìn)行測試，即使很大的測試套件也能輕松在一分鐘內(nèi)跑完。

以 Doctrine 2 為例，此項(xiàng)目的測試套件目前包含了大約1000個(gè)測試，其中將近一半訪問了數(shù)據(jù)庫。但是在一臺(tái)安裝了MySQL的普通的臺(tái)式機(jī)上，整個(gè)測試套件依然能在15秒鐘內(nèi)跑完。