-1

我正在使用 LocomotiveJS 构建 MVC 应用程序。我一直在考虑我应该编写的测试类型并且感到困惑。

以下是应用程序中的不同组件 - 模型、视图、控制器、路由器和 ORM。

如果我必须对每个组件进行单元测试，那么我认为我应该这样做。

  1. 编写测试以确保 ORM 提供的 API 以我期望的方式运行。
  2. 单元测试我的模型存根 ORM。我为它提供了存根，因此我不必在单元测试中依赖实际的数据库操作。
  3. 控制器访问视图和模型。控制器的工作是获取/修改模型并响应客户端（渲染/重定向）。
    • 可以通过向控制器提供测试输入并检查是否生成了正确的响应来测试控制器的响应（存根render/redirect并确保进行了正确的调用）。
    • 可以通过存根模型并确保进行正确调用来测试控制器对模型的操作。这感觉不对，因为我正在测试实现......
  4. 视图只是模板；控制器将模板与值绑定。我可以创建一个假视图模型并将其绑定到视图并查看是否生成了正确的输出。
  5. 路由只是接受请求并将其映射到正确的控制器和操作。我可以通过删除部分路由器并确保对路由器的请求映射到预期的控制器/动作来确保应用程序支持正确的路由。

假设我现在更改了模型 API，我必须更改模型测试，我必须更改控制器测试使用的模型存根，并且我必须更新控制器测试中的断言。

这似乎有点矫枉过正。

这是否有意义？

像上面那样做1和2。

3.集成测试其余部分（控制器/视图/路由器）。test在这里，我认为我应该在一个环境中启动我的应用程序并使用它supertest来确保请求生成正确的响应 - 访问一个 url，我得到正确的内容，正确的重定向等。

我认为对模型进行单元测试是有意义的，因为它代表了与不同系统的交互（数据持久性）。我们要确保桥接功能正常。路由器/控制器/视图在我们自己的系统中以非常特定的方式进行交互。所以集成测试似乎没问题。你觉得呢？你有没有什么想法？

4

1 回答 1

0

如果您依赖集成测试，您将失去单元测试的好处。您的测试将运行得比他们需要的要慢，因此运行频率会降低。你的测试不会告诉你你在哪里弄坏了东西。您的测试不会使用应用程序的尽可能多的功能。您的测试将只有文档的一半有效。您将无法进行 TDD。

总的来说，任何时候有人为了速度而选择放弃单元测试，他们都会走得更慢。

于 2013-03-13T01:01:15.620 回答