當(dāng)我們提到數(shù)據(jù)庫測試時，有一件事是公認的：這不是一件容易的事。在最近一期的JAX雜志中，代表JAX發(fā)言的測試大師Colin Vipurs總結(jié)了測試數(shù)據(jù)庫常用方法的優(yōu)點和缺點。

在我從事軟件開發(fā)的這些年，曾在許多不同的數(shù)據(jù)庫上執(zhí)行過各種級別和類型的測試實例，其中包括RDBMS和NoSQL。它們有一個共同點——很難。因此，我在這里向大家分享一些測試數(shù)據(jù)庫時的一些方法，并指出這些方法各自的優(yōu)點和缺點。

模擬（Mocking）

這種方法我過去常用，但現(xiàn)在我不建議大家繼續(xù)使用。在我的《測試也需要熱愛》（《Tests Need Love Too》）一書中，詳細討論了為什么決不能模擬任何第三方接口。沒看過這本書也沒有關(guān)系，我會在這里再次強調(diào)一遍。

一般情況下，你會用你認為的方式去模擬第三方接口的代碼，但其實你并不知道它真正的代碼是什么。這一點很重要，它很可能會導(dǎo)致錯誤的出現(xiàn)。除非你有更高級別的測試覆蓋你的代碼，但結(jié)果出來之前你沒法確定這樣的級別。此外，模擬原始JDBC真的很難。例如，測試示例1中的那小段代碼。

在這個測試中，不僅需要大量的預(yù)期設(shè)置，還需要驗證所有的請求都有正確的響應(yīng)，jMock “states”被廣泛使用。由于JDBC工作方式的限制，這個步驟違反了模擬測試的規(guī)則——不能越過當(dāng)前的級別進行測試模擬。所以，即使你的測試結(jié)果表明所有工作都可以正常進行，但是當(dāng)按照這樣的代碼進行生產(chǎn)時還是會出現(xiàn)錯誤。

直接在數(shù)據(jù)庫測試

這聽起來好像很瘋狂，但這是最好的方法來驗證數(shù)據(jù)庫之間代碼的交互是否按照預(yù)期運行的。同樣，你還要確保你使用了正確的API。這種技術(shù)可以做到模式測試永遠不可能完成的效果，例如，使你的SQL語法正確并達到你預(yù)期的效果。

內(nèi)存數(shù)據(jù)庫：使用e.g.H2內(nèi)存版本，這是設(shè)置數(shù)據(jù)庫測試的一個最簡單快捷的方式。如果你愿意為你的代碼引入Spring，那么測試設(shè)置也會變得一樣簡單。

這段代碼創(chuàng)建了一個H2數(shù)據(jù)庫實例，并加載了在schema.sql和test-data.sql的測試數(shù)據(jù)中定義的模式。返回對象工具為javax.sql。使得源數(shù)據(jù)可以直接進入到需要它的類別中去。

這個方法的好處之一是快。你可以為你的每個測試需求建立一個新的數(shù)據(jù)庫，為你得到的數(shù)據(jù)準(zhǔn)確性提供堅實的保障。這些都可以在JVM中完成，因此你的開發(fā)平臺上不需要額外的基礎(chǔ)設(shè)施。

這種方法同樣存在著一些缺點。除非你在測試中使用完全相同的內(nèi)存數(shù)據(jù)庫，否則會不可避免的遇到兼容性問題。因為源數(shù)據(jù)的不同，很容易錯過正確的驅(qū)動操作的配置選項。最近我看到這樣的設(shè)置，在H2上配置使用了一個精確到毫秒的DATATIME column。在MySQL生產(chǎn)實例上使用同樣的模式定義，不僅需要DATATIME(3)，還需要參數(shù)useFractinalSeconds=true。這個從H2遷移到MySQL實例上的問題直到測試后才被發(fā)現(xiàn)。

實時數(shù)據(jù)庫

我強烈推薦測試盡可能在生產(chǎn)環(huán)境中進行。但是因為各種各樣的原因使它很難實現(xiàn)，比如在每臺開發(fā)平臺上安裝商業(yè)數(shù)據(jù)庫非常昂貴。有一個經(jīng)典的方法可以繞過這個問題，就是可以給每個人提供單獨的開發(fā)數(shù)據(jù)庫。這就會導(dǎo)致一系列的問題，不僅僅是性能（因為總是被安裝在便宜老舊的硬件上）和測試重復(fù)性的問題。當(dāng)兩個或兩個以上的人共享數(shù)據(jù)庫，然后同時運行測試時，可能會有不一樣的結(jié)果和不可預(yù)料的改變。隨著人數(shù)的增加，這樣的情況會更加嚴重。你會浪費很多時間重新運行測試，并試圖找出更加穩(wěn)定的構(gòu)建。

當(dāng)你使用一個免費的MySQL數(shù)據(jù)庫或免費的NoSQL選項，在開發(fā)平臺中仍然會出現(xiàn)一些問題。例如，需要同時運行多個版本，或者需要通知他們需要構(gòu)建怎樣的基礎(chǔ)設(shè)施和怎樣的接口。在這之前，我們還需要在培訓(xùn)新員工上花費更多的時間。

值得慶幸的是近幾年出現(xiàn)了一些工具來幫助我們緩解這個問題，最顯著的有Vagrant和Docker。例如，Docker中的內(nèi)置MySQL版本可以輕松的發(fā)出一下命令：

$ docker run -p 3306:3306 -e MYSQL_ROOT_PASSWORD=bob mysql

這將使用提供的根密碼，啟動一個最新的MySQL獨立版本映射到本地3306端口。我使用的四年前的蘋果筆記本，在最初的映像下載之后，只需要12秒的時間。如果你需要運行Redis 2.8，就在Docker上這樣寫：

$ docker run -p 6389:6389 redis:2.8

或者在不同的本地端口運行最新的Redis版本：

$ docker run -p 6390:6389 redis:latest

這將很容易的插入到你的構(gòu)建系統(tǒng)中，使整個過程自動化。這就意味著開發(fā)者只需在本地機器上安裝Docker (或Vagrant)即可，并且可以將需要的基礎(chǔ)設(shè)施打包到腳本文件中。

測試方法

當(dāng)你的數(shù)據(jù)庫建立并運行起來后，這時你將面臨新的問題：我該怎么測試？根據(jù)實際情況的不同，測試方法也要相應(yīng)改變。一個新建項目的初期階段我們會關(guān)心關(guān)系模式在怎樣迅速的變化。而一個既定的項目我們會更關(guān)注怎樣讀取現(xiàn)有的數(shù)據(jù)。 大多數(shù)情況使用Redis可以進行高速緩存，所以讀取現(xiàn)有數(shù)據(jù)會更容易些。（不是所有情況都可以，比如當(dāng)Redis是主數(shù)據(jù)存儲器時。）

對于功能性測試，首先注意的是要使用干凈的空數(shù)據(jù)庫。測試的重復(fù)性很關(guān)鍵，一個空的數(shù)據(jù)庫可以確保這一過程的正確性。我通常會在測試開始的時候清除所有數(shù)據(jù)，而不是結(jié)束的時候。這樣在測試失敗的時候，可以方便查看數(shù)據(jù)來診斷問題。就以這樣的方式，重復(fù)你的測試就可以了。

目前流行使用一個叫DbUnit的工具，用來表達數(shù)據(jù)文件并可以輕松的加載測試數(shù)據(jù)。這時有兩個問題需要注意。第一，你使用的數(shù)據(jù)庫是否存在數(shù)據(jù)庫架構(gòu)本身和測試數(shù)據(jù)之間的重復(fù)。因為無論是架構(gòu)的改變，還是測試數(shù)據(jù)不再在測試類本身的改變，都會導(dǎo)致數(shù)據(jù)集文件的變化。可以參見示例3，DbUnit的XML文件。

另一個問題，新手常常會問驗證是否可以避開數(shù)據(jù)庫直接進行。數(shù)據(jù)回路測試（round-trip the data）是測試環(huán)節(jié)中一個重要的部分，因為你要確保你的數(shù)據(jù)可以被回讀。這個問題本質(zhì)上是你在同時測試兩個項目，因此當(dāng)出現(xiàn)故障時，你不能確定是哪里出了問題。如果你使用TDD（這是肯定的），那么問題就是運行與暫停之間的頻率不如以往高，不再需要以往那樣的快速反饋了。

這里我將這兩種測試方法結(jié)合起來，可以避免它們的缺點。第一個是我寫的一個純粹的讀寫測試，可以將數(shù)據(jù)手動輸入而比依賴測試本身。這樣的工作看起來重復(fù)繁瑣，寫入路徑還可能使測試代碼繞過一些邏輯關(guān)系。

例如，插入一個“ON重復(fù)鍵”（ON DUPLICATE KEY）就不必這樣做了。我們假設(shè)記錄不存在，測試的數(shù)據(jù)狀態(tài)完全可控。然后該測試將使用產(chǎn)品代碼回讀測試中插入和標(biāo)記的內(nèi)容，并且回讀的內(nèi)容可以被驗證。請參見示例4的讀取測試。

一旦讀取路徑可用，寫入測試將使用生產(chǎn)代碼生成數(shù)據(jù)回路同時用來寫入和讀取。因為我們已經(jīng)知道讀取路徑完好，所以只需要關(guān)心寫入路徑就可以了。當(dāng)讀取路徑出現(xiàn)故障時也會導(dǎo)致寫入測試的失敗。但是當(dāng)寫入路徑出現(xiàn)故障我們就可以找出問題的所在。此外，如果你使用DSL測試驗證讀取路徑，將會大大節(jié)省你的時間。請參見示例5的回路測試。