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

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

概要：

• 数据库单元测试的策略
• 一般处理方式
• 遇到的问题以及处理思路

---

数据库单元测试的策略

毫无疑问，数据库数据模拟单元测试是有必要的，而且需要通过集成测试方式真正在数据库环境中做到
数据在事务中控制，通过回滚，零污染，数据没有真正添加到数据库
通过数据测试父类或委托方法方式来封装事务相关代码
要考虑应对数据模型变化时的应对，我使用的是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


---