3

I have a business logic layer with a broad spectrum of classes and their corresponding methods. Creating a Unit Test for a method is generally a given but, in some cases, the method really just returns a set of matching records from the database. It seems kind of silly to write a Unit Test by, say, storing five matching records and then calling the BLL method and see if it returns all five records.

What is best practice here? What do you actually do - as opposed to what you'd like to say you would ideally do?

4

2 回答 2

4

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

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

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

  1. 由于该方法位于业务逻辑层（在您的情况下），因此该方法可能最终会变得更加复杂。现在添加单元测试将确保即使在将来，无论逻辑如何，该方法仍会针对意外行为进行测试。

  2. 如果有任何逻辑（例如确定哪些记录符合业务标准），您仍然必须测试该逻辑。

  3. 如果您最终将该方法移动到数据层，您应该针对一些模拟数据存储库测试您的查询，以确保您的查询有效。这样，如果您的查询在未来变得更加复杂......您将被覆盖。

于 2010-01-20T23:15:25.210 回答
0

I use DBUnit to fill in the database with a number of records, more than should be returned by the query. Then, call the method, and make sure that only the right records are returned. This ensures that your query logic works, and helps to catch regression issues in the future if you refactor the database.

于 2010-01-20T22:46:08.803 回答