如何对数据进行单元测试查询？答案

【问题标题】：How unit test queries on data?如何对数据进行单元测试查询？
【发布时间】：2014-01-05 02:13:14
【问题描述】：

如何对一个相当简单的应用程序进行单元测试？

通过“相当简单的应用程序”理解：

通过 ORM 查询数据库（可能很复杂）并显示结果而不进行任何进一步处理的应用程序。也就是说，Linq 查询返回一个简单的IEnumerable，它将显示在屏幕上。

到目前为止，我正在编写的那种测试往往很慢，而且我越来越延迟它们的执行。如果我保持这个过程，这些测试只会在我提交代码时执行，因此我将失去单元测试的所有好处：在一分钟内突出显示错误或错误。

我试图在内存中创建一个对象图，但是随着应用程序的增长，这个图变得非常复杂，并且需要越来越多的时间来维护。当我插入 ORM 而不是对象图时，我看到了我的单元测试没有预见到的错误......

就我而言，我需要一个通用的解决方案，因为 ORM 应该是实体框架或 nHibernate。

编辑：

我重新表述我的问题，因为它可能有点不清楚：测试这种应用程序意味着测试查询。 测试 Linq 查询的最佳方式是什么？

【问题讨论】：

这完全不清楚。你到底想测试什么？做什么的？有样品吗？ ...
这是非常基于意见的，所以没有答案。但我相信 EF 和 nHibernate 可以工作，不需要进行测试。我做什么：我使用服务实现中的任何 ORM。然后，该服务由进行额外处理/验证的 Facade 类使用。我有一个使用 ORM 的服务版本和一个使用基于内存的数据的服务版本。然后我经常使用基于模型内存的服务来测试 Facade。不太常见的是基于 ORM 的服务。这可以防止基于 DB 的 ORM 导致执行缓慢。
这是一个非常广泛的问题。或许你可以在programmers.stackexchange.com上问
我编辑我的问题以澄清它。

标签： c# unit-testing

【解决方案1】：

您的问题的简单答案不是对数据查询进行单元测试。当您发现单元测试的价值时，这部分应用程序非常有限，并且大多数错误都没有出现。 ORM 是进行集成测试的好地方。

要启用此功能，您的数据访问代码必须放在一个位置。根据您的应用程序，这可能是数据访问层、存储库或任何其他使您能够将业务逻辑与数据访问分离的结构。在业务逻辑部分，您使用单元测试并使用内存解决方案模拟或替换数据访问。您使用集成测试测试的数据访问部分。但在这里，您只需测试您是否可以插入、更新、选择或删除数据，以及您的查询是否有效。与尝试在单元测试中完成这一切相比，这应该可以通过更少的测试来实现。

Entity Framework 和 nHibernate 都有关于如何使用这些框架进行此类测试的教程。

【讨论】：

【解决方案2】：

Johnny Graber 的回答与此类似，但我还是会添加我的回答，以征求一些意见。

要专门回答您测试 Linq 查询的问题（我仍然认为，就像上面的评论一样）：您不测试它们。

虽然 Linq 既美观又简单，但在项目中拥有大量 Linq 查询基本上和硬编码 SQL 语句一样糟糕。

因此，Linq 查询应该是数据抽象层的一部分，而该层就是您要测试的。该层提供基本的访问方法，主要是 CRUD 操作。这些操作可以使用 Linq 针对任何对象（SQL、SQLite.Net、XML 等等）来实现。

然后，您应该有另一个 DAL 实现，它返回/生成模拟数据。此处无需使用 Linq。

然后您可以测试，如果您的应用程序针对包含模拟数据的实现工作，这很快，因为它是基于内存的。您担心这些方法的结果。

您可以不时切换到基于 Linq 的生产版本并运行较慢的测试。 Linq 本身可以工作。微软做得很好。您需要担心您的访问方法会返回正确的数据。

【讨论】：