数据库单元测试的一点尝试

数据库单元测试的一点尝试

概要：

数据库单元测试的策略

一般处理方式

遇到的问题以及处理思路

数据库单元测试的策略

毫无疑问，数据库数据模拟单元测试是有必要的，而且需要通过集成测试方式真正在数据库环境中做到

数据在事务中控制，通过回滚，零污染，数据没有真正添加到数据库

通过数据测试父类或委托方法方式来封装事务相关代码

要考虑应对数据模型变化时的应对，我使用的是UnitOfWork设计模式封装的EntityFrameowrk，Code First方式处理数据访问层，所以数据模型会经常剧烈变化，之前就这里遇到了问题，后面会提及

一般处理方式

代码块

数据测试基类DBTestBase，网上也有类似的代码，关键代码例如：

#`这里写代码片`region 成员变量区域
private TransactionScope _scope;
#endregion

#region 每个测试方法调用前初始化，均打开独立的事务作用域
[TestInitialize]
public virtual void Setup()
{
_scope = new TransactionScope();
}
#endregion

#region 每个测试方法调用后触发，独立的事务销毁，回滚操作，不提交事务
[TestCleanup]
public virtual void TearDown()
{
_scope.Dispose();
}
#endregion

#region 默认初始化IOC组件
/// <summary>
/// 默认初始化IOC组件
/// 模型变化时处理方式
/// </summary>
protected static void Init()
{
BootStrapper.InitMap();
//模型变化时处理
HandleIfModelChangeThenCreateOrDropDBThrowTransactionException();
}

遇到的问题以及处理思路

代码块

测试方法都包裹在外层事务中，模型变化时，EntityFramework都会根据数据库初始化设置，对已存在数据库进行删除，就会抛出SqlException，提示不能在事务中执行DropDataBase命令，那我就写了个不优美然而还真有用的方法HandleIfModelChangeThenCreateOrDropDBThrowTransactionException()，在里面就执行简单查询，就可以让数据库适应模型变化，然后再去执行包裹在事务控制中的测试方法，例如：

C#

/// <summary>

/// 使用了一种取巧的做法处理因模型改变引发数据库创建或删除，因使用外层事务包裹，会发生异常的情形

/// </summary>

private static void HandleIfModelChangeThenCreateOrDropDBThrowTransactionException()

{

using (GeneralDataContext ctx = new GeneralDataContext())

{

ctx.Members.Count();

}

}

#endregion