代码之家 › 专栏 › 技术社区 › bryanjonker

单元测试和数据库

maintainability mocking unit-testing c#

3

bryanjonker · 技术社区 · 14 年前

This question about unit tests

创建模拟对象并将其插入。这样做的好处是不需要数据库,但很费时,而且我也不知道我能得到多少投资回报。我已经进入了国际奥委会和最低起订量一点,但它仍然似乎痛苦。
手动检查dev数据库并修改单元测试。密集的手工工作,但如果我有一个“测试集”不变,它似乎工作正常。在我的机器上,至少:-)。

如果上下文有帮助的话,我在一家C#商店里写内部应用程序,只有几个开发人员。

4 回复 | 直到 7 年前

1

3

Stephen Cleary 14 年前

如果你有一个数据访问层,它只公开了一小部分数据,那么第一个就不会那么难了 IQueryable<T> 方法。有一个很好的技巧可以用来处理假数据:只需将实体对象存储在 List<T> 使用 AsQueryable

关于IOC,我的立场是,它目前被过度使用(请注意,我的观点代表了这方面的少数程序员)。你可以使用像 Moles 在测试过程中,可以模拟而不必滥用程序的设计。除非设计需要,否则我不会使用IOC。

2

jyoungdev Thilo 14 年前

我肯定会继续使用真正的单元测试(选项1)。我喜欢斯蒂芬的建议。

必要的 也可以使用(选项2)。为什么?因为真正的单元测试不包括您需要测试的部分内容(O/R映射、与实际DB模式的兼容性等)。

至于安装和拆卸逻辑,从中继承通常就足够了(对数据库使用.NET、NUnit和SqlServer):

using System.Transactions;
using NUnit.Framework;
namespace Crown.Util.TestUtil
{
    [TestFixture]
    public class PersistenceTestFixture
    {
        public TransactionScope TxScope { get; private set; }

        [SetUp]
        public void SetUp()
        {
            TxScope = new TransactionScope();
        }

        [TearDown]
        public void TearDown()
        {
            if (TxScope != null)
            {
                TxScope.Dispose();
                TxScope = null;
            }
        }
    }
}

很简单。

3

1

drekka 14 年前

了解这一点也将帮助您决定测试事物的最佳方法。从我所看到的情况来看,还有一种方法可以替代你列出的方法。即在内存数据库(如hsql)中启动并运行类和测试。这意味着您可以在测试开始时创建数据库结构。因为它在内存中,所以您不必担心有数据库服务器,它很快,而且您可以用特定于测试的数据加载它。

我经常使用mock,虽然它们非常适合对类进行单元测试,但在某些情况下它们不是。他们也很容易错过铅。与mock一起工作的东西在集成时不工作并不少见。这样做的原因是,您正在加载带有某些期望和响应的mock,这些期望和响应可能是您错误地从mock所表示的事物中解释出来的。

4

0

Mahol25 14 年前

你到底在测试什么让你觉得这很困难?

如果您将业务层和服务层逻辑与持久性代码分离,那么您应该能够轻松地隔离要进行单元测试的代码,而不必使用DB。

单元测试最重要的原则之一是解耦和隔离测试。当您清楚地了解如何做到这一点时,单元测试就很容易了。如果不这样做,单元测试就会变得很困难。