Question

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

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

Answer 1

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

private IList<User> _allUsers;

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

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

Answer 2

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

我喜欢使用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

Answer 3

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

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

每个单元测试都应讲述一个关于被测课程的故事（c）。太多无用的单元测试可能会隐藏有关您系统的相关或重要信息，并且实际上会降低可维护性而不是增加它。

务实并将测试添加到系统的大多数重要部分，并首先涵盖最复杂的业务逻辑，然后转向系统的其他部分。

单元测试模型 - 建议

3 个答案: