集成测试数据库，我在做对吗？

问题描述

我要测试的依赖和使用数据库我MVC4应用方法。我不想用模拟的方法/对象，因为该查询可以复杂，创建测试对象，因为这是太多的努力。

我发现，在包装完成后回滚更改的的TransactionScope 对象测试的数据库操作逻辑集成测试的想法。

不幸的是，这并不起初一个空数据库开始，这也使得主键上数（即，当有已经与主键1和2中的数据库中的几个项目再经过运行测试它计数与4），我不想这样。

这是一个集成测试，我想出了只是为了测试，如果产品实际添加（例如，我希望创建一个检查方法，一旦我有权利的基础设施，更艰巨的考验）。

  [TestMethod的]
    公共无效ProductTest（）
    {
        //安排
        使用（新的TransactionScope（））
        {
            myContext DB =新myContext（）;
            产品testProduct =新产品
            {
                产品编号= 999999，
                类别ID = 3，
                ShopId = 2，
                价格= 1.00M，
                NAME =试验品，
                可见=真
            };            //法案
            db.Products.Add（testProduct）;
            db.SaveChanges（）;            //断言
            Assert.AreEqual（1，db.Products.ToList（）计数（））;
            //失败，因为有已在数据库中的物品        }    }
 

这引发了很多问题，这里有一个选择：我如何开始建立一个空数据库？我应该附加其他数据库的项目有自己的背景和连接字符串？而最重要的是，我该如何正确地测试，而不毁了我的旧数据一个实际的数据库上的方法？

我一直在忙了一整天试图找出如何单元/集成测试我的数据库逻辑。我希望有经验的开发人员可以在这里提供一些帮助！

/编辑的NDbUnit测试是否会影响/改变我的数据库...

 公共类IntegrationTests
{
    [测试方法]
    公共无效测试（）
    {
        字符串的connectionString =数据源=（的LocalDB）\\\\ 11.0;初始目录= Database_Nieuw;
            集成安全性= FALSE;;
        //以上是唯一可行的ConnectionString的...而且是真正的本地数据库
        //这不是用在詹金斯，但我也许可以将其固定？
        NDbUnit.Core.INDbUnitTest mySqlDatabase =新
        NDbUnit.Core.SqlClient.SqlDbUnitTest（的connectionString）;
        mySqlDatabase.ReadXmlSchema（@.. \\ .. \\ NDbUnitTestDatabase \\ NDbUnitTestDatabase.xsd）;
        mySqlDatabase.ReadXml（@.. \\ .. \\ NDbUnitTestDatabase \\ DatabaseSeeding.xml）; // 数据
        mySqlDatabase.PerformDbOperation（NDbUnit.Core.DbOperationFlag.CleanInsertIdentity）;
}
 

解决方案

This is the right strategy. Most "interesting" bugs tend to happen at the "boundary" between client code and the (real) database.

Purge the database programmatically before each test. You can automate that by putting the purging code in a method marked with [TestInitialize] attribute. If your database happens to use ON DELETE CASCADE, deleting all data might be as simple as deleting few "top" tables.

Alternatively, just write your tests to be resilient in case there is already some data in the database. For example, each test would generate its own test data and use the specific IDs of the generated data only. This allows you better performance as you don't need to run any extra purging code.

Forget about it. Never run such tests on anything but a development database that you can throw-away as needed. Sooner or later you will commit something you did not intend to, or hold some lock longer than acceptable in production (e.g. by hitting a breakpoint in the debugger), or modify the schema in an incompatible manner, or just hammer it with load tests that would otherwise affect the productivity of real users...

这篇关于集成测试数据库，我在做对吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！