正文
作者水平有限，如有錯誤或紕漏，請指出，謝謝。
背景介紹
最近在團隊在做release之前的regression,把各個feature分支merge回master之后發(fā)現(xiàn)DB的單元測試出現(xiàn)了20多個失敗的test cases。之前沒怎么做過DB的單元測試，正好借這個機會熟悉一下寫DB單元測試的流程。
這篇博文中首先介紹一下在我們的特定項目場景中是如何搭建DB 單元測試框架的，然后舉一個簡單的例子，從頭到尾在visual studio中創(chuàng)建一個簡單的單元測試工程。
我們開發(fā)的產(chǎn)品使用的數(shù)據(jù)庫為Sql Server,總共有400多張表，2000多個存儲過程，每個存儲過程都相當于應(yīng)用代碼中的一個功能函數(shù)。代碼中的每個復雜的功能函數(shù)都可以通過寫單元測試來在一定程度上保證代碼質(zhì)量，存儲過程也如此。代碼中的UT難點在于解耦，也就把相互牽連在一起的代碼彼此分離開來，各個擊破，例如A函數(shù)需要B函數(shù)提供的數(shù)據(jù)，測試A函數(shù)的時候我們只想測試A函數(shù)，不想調(diào)用B，這時候就需要我們自己提供B函數(shù)生成的數(shù)據(jù)。這叫做mock。
在做DB單元測試的時候，存儲過程所使用的數(shù)據(jù)比較特殊，都是持久化在數(shù)據(jù)庫表中的，2000多個存儲過程增刪改查400多個表，我們需要把這些表的數(shù)據(jù)為每個存儲過程做隔離，如果測試用例使用的數(shù)據(jù)相互之間關(guān)聯(lián)，恐怕會天下大亂，因為在一般情況下，單元測試用例的運行順序都是隨機的，如果單元測試使用的數(shù)據(jù)有關(guān)聯(lián)，很有可能兩次運行結(jié)果也是隨機的（但是有一種方法可以固定case執(zhí)行順序，我在最后的例子中進行說明），我們這次的20多個失敗的cases就有這種原因?qū)е碌?，兩臺機器上跑出的結(jié)果不一樣，有的成功，有的失敗。
注：有關(guān)單元測試的定義，見另外一篇帖子，單元測試有毒
那么問題就來了，如何才能做數(shù)據(jù)的隔離呢？說一下我們的方案。
