您是否应该对主要包含查询的业务逻辑方法进行单元测试？答案

【问题标题】：Should you Unit Test Business Logic methods that consists primarily of a query?您是否应该对主要包含查询的业务逻辑方法进行单元测试？
【发布时间】：2010-01-20 22:41:30
【问题描述】：

我有一个业务逻辑层，其中包含广泛的类及其相应的方法。为方法创建单元测试通常是给定的，但在某些情况下，该方法实际上只是从数据库中返回一组匹配的记录。通过存储五个匹配的记录然后调用 BLL 方法并查看它是否返回所有五个记录来编写单元测试似乎有点愚蠢。

这里的最佳做法是什么？您实际上做什么 - 而不是您想说的理想情况？

【问题讨论】：

+1 表示“你实际上做了什么”
大声笑-谢谢。当日程安排很紧时，我通常会比实际练习高一个档次。这提醒了我...我有一些单元测试要写。

标签： unit-testing business-logic

【解决方案1】：

我相信这里真正的问题是，为什么您的业务逻辑层中的方法似乎不包含任何真正的业务逻辑？

在这种情况下，所讨论的方法似乎只是一种存储库风格的方法，用于从数据库中检索符合某些条件的记录。

在任何一种情况下，我仍然会对该方法进行单元测试。有几个原因：

由于该方法位于业务逻辑层（在您的情况下），因此该方法可能最终会变得更加复杂。现在添加单元测试将确保即使在将来，无论逻辑如何，该方法仍会针对意外行为进行测试。
如果有任何逻辑（例如确定哪些记录符合业务标准），您仍然需要测试该逻辑。
如果您最终将该方法移至数据层，您应该针对一些模拟数据存储库测试您的查询，以确保您的查询正常工作。这样一来，如果您的查询在未来变得更加复杂……您就可以得到保障。

【讨论】：

拥有这些方法的原因是我不想在 UI 代码中调用数据层。在我的例子中，数据层也很薄：一个流畅的界面，使查询变得容易（连同一个 T-SQL 代码生成器，所以我在处理数据时通常使用强类型的类实例）。跨度>

【解决方案2】：

我使用DBUnit 在数据库中填写了多条记录，超过了查询应该返回的记录。然后，调用该方法，并确保只返回正确的记录。这可确保您的查询逻辑正常工作，并有助于在将来重构数据库时发现回归问题。

【讨论】：