1

我刚刚读完“使用 C# 进行专业测试驱动开发”，并一直在尝试找到一种方法来在我的代码中实现 100% 的覆盖率。这一切都很好，直到我找到一个充满了实现如下方法的存储库类：

public IEnumerable<MyDataContract> LoadConditional(bool isCondition)
{
   const string QUERY = @"SELECT ...fields... FROM MyData WHERE [IsCondition] = @IsCondition";
   return DataAccessor.ReadMyContracts(QUERY, isCondition); // something, something...
}

我一直在考虑这个问题，并且无法在互联网上找到直接回答这个问题的答案。

  • 我读到的东西表明与 SQL 相关的业务将存在于另一个程序集中。不过我不需要这个，也不相信我应该去那里。而且，从代码覆盖率来看，这是一个非常肤浅的变化。

  • 我读过你可以为你的单元测试连接数据库（我以前做过）。但这很好……我不知道，感觉不对。测试速度很慢，并且维护量显着增加。

我的直觉是，如果没有我提到的最后一点，这种方法就不能进行单元测试。我应该如何看待这个问题？

4

2 回答 2

6

首先让我说，我认为实现 100% 的覆盖率完全没有意义，也证明不了任何事情。

话虽如此，我通常在 DB 和业务逻辑之间使用一些层——一些简单的映射器（PetaPoco、Dapper、OrmLite），或者很少使用完整的 ORM（NHibernate）。

在我需要对数据库进行集成测试的情况下，这些工具允许我对测试数据库（例如内存中的 SQLite DB）而不是“真正的”数据库服务器运行相同的查询。

关于您对“测试速度慢并且维护量显着增加”的担忧。您应该记住，这些不再是单元测试 - 这些是集成测试，它们不能像单元测试那样快。

于 2013-03-11T14:07:33.287 回答
0

在我看来，如果您进行实际的数据访问，您将进入集成测试并离开单元测试领域。我个人更喜欢仅将 SQL 保留在数据访问层内，即在数据库本身之前的单层，然后我测试所有内容。在我看来，一个名为的方法ReadMyContracts应该已经具有用于访问数据的正确 SQL，并且应该只接收（并传递）isCondition参数。

那只是MHO。

于 2013-03-11T14:10:13.977 回答