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

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

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

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

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

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

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

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

測試代碼應當盡可能簡短精確，這有若干原因：

• 你不希望因為生產(chǎn)代碼的小變更而需要對測試代碼進行數(shù)量可觀的修改。

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

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

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

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

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