4

我有一个多人参与的项目。我一直在为我们的项目构建单元测试。（我知道这些应该从第一天开始就在那里，但我是在项目开始后加入的。）

我们有很多模型，有很多属性。我想知道您是否会建议我创建单元测试来测试这些模型是否正确实例化并设置属性？

4

3 回答 3

1

我不会测试它们是否为 ORM 框架正确加载。但是，如果它们有一些逻辑，我会添加测试，例如：

private IList<User> _allUsers;

public IEnumerable<User> GetActiveUser
{
   get { return _allUsers.Where(u => u.IsActive);
}

这可能需要一些测试来确保您只获得活跃用户。

于 2012-11-27T20:03:49.003 回答
1

测试模型是否被您使用的任何框架或数据访问层以及模型本身内置的任何业务逻辑正确持久化。

我喜欢使用 NUnit + Fluent Assertions 在持久性操作之前和之后比较模型（例如创建和保存模型，并确保它正确检索所有值）。

请注意，它不一定是持久性。也许您的模型是一个视图模型，并由映射器从业务实体映射。我也会测试一下。基本上，您想测试模型是否正确地通过了某些层或逻辑，而不是测试模型本身（当然，除了内置的任何业务逻辑）。测试语言或框架特性/编译器是否正常工作，就像测试属性工作的情况一样，在我看来是浪费时间。

粗略的例子：

  // arrange
  var expected = new PersonModel
                  {
                     FirstName = "John",
                     LastName = "Doe",
                     DateOfBirth = DateTime.Now
                     // etc
                   }

   // act
   var id = InsertModelAndReturnId(expected);
   var actual = RetrieveModelById(id);

   // assert
   actual.ShouldHave().AllProperties().EqualTo(expected); // ShouldHave is from Fluent Assertions. This line makes sure expected and actual have the same values after being persisted and retrieved
于 2012-11-27T20:08:51.053 回答
0

在大多数情况下，您应该专注于逻辑而不是数据。这意味着您不应该测试state，而应该测试行为。

您的属性背后可能有一些行为。例如，改变一个属性的状态应该会影响其他一些属性的值（但在这种情况下，我们仍然会测试行为而不是状态）。

每个单元测试都应该讲述一个关于被测类的故事 (c)。太多无用的单元测试会隐藏有关系统的相关或重要信息，实际上会降低而不是增加可维护性。

务实，将测试添加到系统的最重要部分，并首先涵盖最复杂的业务逻辑，然后将它们移至系统的其他部分。

于 2012-11-27T20:19:44.630 回答