單元測試要求：單元測試方法并不真正去變更數(shù)據(jù)庫，也是說單元測試不依賴于數(shù)據(jù)庫中的數(shù)據(jù)。那我們?nèi)绾谓鉀Q執(zhí)行單元測試方法后，不變更數(shù)據(jù)庫中數(shù)據(jù)呢？
一般的解決方案有兩種：
1、 新建一個單元測試數(shù)據(jù)庫，開發(fā)數(shù)據(jù)庫與單元測試數(shù)據(jù)庫分離，單元測試方法完全基于單元測試數(shù)據(jù)庫。
此中方法的優(yōu)點是：，開發(fā)人員在開發(fā)期間不會對單元測試數(shù)據(jù)庫中數(shù)據(jù)進行變更，也不會影響單元測試方法 在任何時間執(zhí)行。
缺點：單元測試數(shù)據(jù)庫和開發(fā)數(shù)據(jù)庫同步問題，特別是對迭代式開發(fā)項目，數(shù)據(jù)庫是根據(jù)需求在不斷地跟進或者變更，同步問題成為了單元測試正常運行的瓶頸。
2、 使用事務對單元測試方法的執(zhí)行進行回滾。
此種方法的優(yōu)點：解決了方法一中缺點，不會出現(xiàn)數(shù)據(jù)庫結構不同步的問題。
缺點：在進行CRUD（Create/Read/Update/Delete）操作時，需要在單元測試方法中進行一些插入數(shù)據(jù)操作，從而保證單元測試與開發(fā)數(shù)據(jù)庫的獨立，造成了單元測試工作量增加。
在實際的項目中，可以根據(jù)需要選擇符合自己的解決方案，如果數(shù)據(jù)庫結構在項目進入開發(fā)階段已經(jīng)確定，并且以后不會有變動，建議采用第一種方案，否則建議第二種方案。目前我們項目采用第二中方案。
一、NUnit事務性單元測試
那使用Nunit框架如果保證數(shù)據(jù)的會滾呢？這里我們使用了COM+事務。
即System.EnterpriseServices;
具體如下：
/// <summary>
///單元測試基類，所有單元測試類都需要繼承此類
/// </summary>
[TestFixture]
[Transaction(TransactionOption.Required)]
public class DatabaseFixture:ServicedComponent
{
public DatabaseFixture()
{
//
// TODO: Add constructor logic here
//
}
[TearDown]
public void TransactionTearDown()
{
if (ContextUtil.IsInTransaction)
{
ContextUtil.SetAbort();
}
}
所有的單元測試方法都需要繼承與此類。比如：
public class AddressSqlDAOTest : DatabaseFixture
這樣，單元測試方法執(zhí)行完后，會繼續(xù)執(zhí)行DatabaseFixture類中的TransactionTearDown()方法。從而會滾之前的數(shù)據(jù)操作，單元測試方法也不會影響開發(fā)數(shù)據(jù)庫，同樣開發(fā)數(shù)據(jù)庫也不會影響單元測試方法的執(zhí)行，從而保證了單元測試與數(shù)據(jù)庫數(shù)據(jù)的獨立。
二、如何CRUD單元測試
1、測試增加方法：判斷返回的主鍵是否>0，如果主鍵>0 說明單元測試方法成功，否則失敗
2、測試查詢方法：首先在執(zhí)行單元測試類中的插入數(shù)據(jù)方法（不是被測試類中的插入方法，而是在單元測試類中寫的插入方法，一定要區(qū)分開），然后執(zhí)行查詢方法。
3、測試更新方法：首先在執(zhí)行單元測試類中的插入數(shù)據(jù)方法，然后執(zhí)行更新方法。
4、測試刪除方法：首先在執(zhí)行單元測試類中的插入數(shù)據(jù)方法，然后執(zhí)行刪除方法。
三、單元測試的命名規(guī)范
為了便于后期單元測試方法的維護，建議如下命名單元測試類 和單元測試方法。
單元測試類名：被測試類名稱+Test
單元測試方法名：被測試方法名稱+Test
四、總結
至此，大家可以利用Nunit中如何進行事務性單元測試已經(jīng)完畢，相信大家也已經(jīng)了解了如何讓單元測試獨立于數(shù)據(jù)庫數(shù)據(jù)，從而更高效地進行單元測試，也不影響開發(fā)。
