我应该在单元测试和集成测试之间划清界限吗？它们应该分开吗？

我有一个正在研究的小型MVC框架。它的代码库肯定不大，但是不再仅仅是几个类。我最终决定尝试一下并开始为此编写测试（是的，我知道我应该一直这样做，但是到目前为止，它的API还是非常不稳定的）

无论如何，我的计划是使其变得非常容易测试，包括集成测试。集成测试示例将遵循以下原则：

伪造的HTTP请求对象-> MVC框架-> HTTP响应对象->检查响应是否正确

因为这一切都可以在没有任何状态或特殊工具（浏览器自动化等）的情况下完成，所以实际上我可以使用常规的单元测试框架轻松地做到这一点（我使用NUnit）。

现在是个大问题。我应该在单元测试和集成测试之间划清界限吗？我是否应该一次（尽可能多地）仅通过单元测试来测试一门课程？另外，是否应该将集成测试与单元测试项目放在同一测试项目中？

集成与单元测试

您应该将单元测试和集成测试完全分开。您的单元测试应该只测试一件事和一件事，并且完全隔离系统的其余部分。单位的定义很松散，但通常可以归结为方法或功能。

对每个单元进行测试很有意义，这样您就可以知道它们的算法正确实现，并且如果实现存在缺陷，您可以立即知道哪里出了问题。

由于您在单元测试时进行了完全隔离的测试，因此您可以使用存根和模拟对象来像其他应用程序一样工作。这就是进行集成测试的地方。单独测试所有单元非常棒，但是您确实需要知道这些单元是否在实际协同工作。

这意味着知道模型是否实际存储在数据库中，或者在算法X失败后是否真正发出警告。

测试驱动开发

退后一步，看看测试驱动开发（TDD），需要考虑几件事。

1. 在实际编写可以通过的代码之前，请先编写单元测试。
2. 您使测试通过，编写足够的代码来完成此任务。
3. 现在测试通过了，该退后一步了。使用此新功能是否可以重构？您可以安全地执行此操作，因为所有内容都已通过测试。

集成优先vs集成最后

集成测试通过以下两种方式之一适合此TDD周期。我认识一些喜欢事先写信的人。他们将集成测试称为端到端测试，并将端到端测试定义为完全测试用例整个路径的测试（例如，设置应用程序，引导应用程序，进入控制器，执行它，检查结果，输出等...）。然后，他们开始进行第一个单元测试，使其通过，再添加第二个，使其通过，等等。慢慢地，越来越多的集成测试部分也通过，直到功能完成。

另一种样式是通过单元测试构建功能单元测试，然后添加认为必要的集成测试。两者之间的最大区别在于，在进行集成测试时，首先必须考虑应用程序的设计。这种不同意TDD与应用程序设计以及测试有关的前提。

实用性

在我的工作中，我们将所有测试都放在同一个项目中。但是有不同的组。持续集成工具首先运行标记为单元测试的工具。只有那些成功了，执行集成测试的速度也会变慢（因为它们发出了真实的请求，使用了真实的数据库等）。

顺便说一句，我们通常对一个类使用一个测试文件。

建议阅读

1. 在测试的指导下不断发展的面向对象软件本书是集成测试优先方法的一个非常好的例子
2. 单元测试的技巧，dot.net中的示例单元测试的技巧，dot.net中的示例：D非常好的书，介绍了单元测试的原理。
3. 罗伯特·马丁（TDC）上的罗伯特·C·马丁（Robert C. Martin）（免费文章）：还要阅读他所链接的前两篇文章。

在任何测试策略中，重要的是测试覆盖率-即能够表明所有功能都在接受测试。

通常，除非您有相反的特定要求（例如，DO178 A级，IEC61508 SIL 4等），在您所处的情况下似乎并非如此，那么如果您可以测试类或模块的完整功能（和在系统级别证明您具有），则系统级别的测试就足够了。依此类推。仅当您没有进一步进行测试时，才需要进行单元测试。

我应该在单元测试和集成测试之间划清界限吗？

鉴于集成测试通常更容易，更快和更便宜，请尽可能地划清界限...

我是否应该一次（尽可能多地）仅通过单元测试来测试一门课程？

再次取决于范围...根据定义，单元测试正在测试单个单元。但是，如果您可以一次性全面测试一个完整的模块，则可以这样做。您实际上一次完成了多个单元测试。

另外，是否应该将集成测试与单元测试项目放在同一测试项目中？

根本没有理由不这样做……除非由独立的测试人员执行更高级别的测试，否则您只应该发布可执行文件和最少的工具。

当我有小的项目时，我只是将所有测试弹出到同一项目中。由于较大的项目将这些拆分，因此我只是确保有必要在可能的情况下将它们分开。

使用单元测试，我通常只测试文件中的一个类（SUT）。