1

在 MVC4 C# 网站中，我们使用单元测试来测试我们的代码。我们目前正在做的是创建一个模拟数据库，然后测试每一层：

  1. 测试数据库 - 连接、初始化、加载等。
  2. 测试访问数据库的代码
  3. 测试视图层

我希望这三个类别按顺序运行，并且只有在前一个类别通过时。这是正确的方法吗？我们使用依赖注入框架的旧方法是一种奇怪的模拟测试方法。我们实际上为每个数据访问器创建了一个模拟类，这很糟糕，因为我们必须重新实现每个方法的逻辑，而且它并没有真正增加任何价值，因为如果我们第一次在逻辑上犯了错误，我们会稍等片刻。

4

1 回答 1

3

我希望这三个类别按顺序运行，并且只有在前一个类别通过时。这是正确的方法吗？

不，您应该单独测试所有内容，因此任何失败的数据访问代码都应该与视图完全无关。因此，视图单元测试应该由于完全不同的原因而失败，因此您应该始终运行所有测试。

一般来说，测试应该独立运行，并且不应该依赖于任何其他测试。在我看来，视图层仍然依赖于数据访问代码，但您只抽象了下面的层。在这种情况下，从视图的角度来看，您正在模拟一个间接依赖，这使得您的单元测试比严格需要的更复杂。

我们使用依赖注入框架的旧方法是一种奇怪的模拟测试方法

我不确定我是否明白这一点，但似乎您在单元测试中使用了 DI 容器。这是绝对不行的。不要使用任何 DI 框架使您的测试变得混乱。而且没有必要。只需围绕依赖注入原则设计您的类（将所有依赖项公开为构造函数参数），然后在您的测试中，您只需使用虚假依赖项手动新建被测类 - 或者 - 当这导致重复代码时，在您的测试中创建一个工厂方法创建被测类的新实例的类。

我们实际上为每个数据访问器创建了一个模拟类，这很糟糕

我不确定，但听起来好像你的设计有问题。你通常会有一个IRepository<T>接口，你会有多个实现，例如 aUserRepository : IRepository<User>和OrderRepository : IRepository<Order>。在您的测试套件中，您将拥有一个通用的FakeRespository<T>或InMemoryRepository<T>，然后您就完成了。无需在这里模拟许多课程。

以下是您绝对应该阅读的两本好书：

  1. 单元测试的艺术
  2. .NET 中的依赖注入

这些书会改变你的生活。既然您无论如何都会阅读，请务必阅读这本书（与您的问题无关，但代码也可以改变生活）。

于 2012-10-31T19:49:16.093 回答