除了数据库，文件系统等的集成测试之外，还需要单元测试吗? [英] Is unit testing needed in addition to integration testing of DB, filesystem, etc.?

问题描述

在我的办公室里，除了主要负责与文件系统(DB等)交互作用的类的集成测试之外，我们还就单元测试的必要性存在争议.

At my office we have a dispute regarding the necessity of unit tests in addition to integration tests for the classes that have the main responsibility of interacting with a filesystem (DB, etc).

我们拥有的集成测试几乎是单元测试，因为被测试的对象根本不与其他对象交互.我们称测试为 integration 的唯一原因是测试中使用了真正的文件系统.并且建议让被测类使用文件系统层组件，然后在测试中对其进行模拟(因此我们将其称为 unit 测试)，并检查与该组件的交互，而不是实际文件系统结果.我们将讨论此更改的必要性.

The integration tests we have, are almost unit tests, as the tested object doesn't interact with other objects at all. The only reason, why we call the tests integration, is that the real filesystem is used in tests. And it is proposed to make the tested class use filesystem layer component, then mock it in tests (so we will call them unit tests), and check interaction with this component, rather than real filesystem results. Necessity of this change is what we discuss.

我们的观点之一是，始终需要进行单元测试，因为:

One point of view we have, is that unit tests are always required, because:

1. 编写单元测试使代码变得更好
2. 具有单元测试，您无需关心真正的文件系统和文件的副作用，它们会出现在错误的位置
3. 开发人员可以通过使被测类使用文件系统模拟并为该模拟设置适当的期望来完全测试结果
4. 将模拟期望值与被测类的特定内部算法联系起来是可以的，因为我们使用单元测试来进行白盒测试

因此，必须始终为此类经过测试的类编写单元测试.而且，出于测试目的，该类必须始终使用文件系统层组件.

Thus, the unit tests must always be written for such a tested class. And a filesystem layer component must always be used by that class for the purpose of testing.

另一观点是，专用于文件系统交互的类的特定边缘情况不需要单元测试，因为:

Another point of view, is that unit tests are not needed for specific edge cases of classes that are devoted to filesystem interactions, because:

1. 仅通过使用简单的模拟而不是真实的文件系统(或其完整仿真)，就不可能正确地验证已测试的类是否有效.文件系统是一个非常复杂的组件，它:
   • 一个经过测试的类可以以多种不同的方式工作以获得成功的结果.模拟期望仅涵盖两种可能的情况，因此单元测试错误地显示了正确实现良好算法的类的失败，这与期望的有所不同.
   • 一个已测试的类可以以某种方式工作(通过模拟检测为成功的情况)，而该类仍然无法产生正确的结果.这可能是由于实际文件系统中的原因非常复杂.所有这些原因不可能仅凭模拟来解决.

1. It is not possible to properly verify, that a tested class works, just by having simple mock instead of real filesystem (or its full emulation). Filesystem is such a complex component, that:
   • A tested class can work in many different ways in order to achieve successful result. The mock expectations cover just one-two possible scenarios, so a unit test erroneously shows failures for a class that properly implements good algorithm, which is different from the one expected.
   • A tested class can work in a way, detected by mock as a successful scenario, while the class still does not produce right result. This can be because of quite complex reasons in real filesystem. All these reasons are impossible to be covered just by a mock.

因此，在我们的案例中，不需要使用文件系统模拟进行单元测试.对于这种特殊的类情况，它是脆弱的，而且不准确.

Thus the unit testing with filesystem mocking is not needed in our case. It is fragile and is not accurate for this particular case of classes.

因此，总而言之，问题是:
对于没有复杂类的边缘情况(对于使用文件系统(DB等)负主要责任)的集成情况，集成测试是否足够充分?

So, to sum it up, the question is:
Is integration testing fully enough for an edge case of having not a complex class, which has main responsibility to work with a filesystem (DB, etc.)?

该类的 integration 和 unit 测试之间的唯一区别是，对于单元测试，将使用文件系统模拟(类将是完全隔离的)，而对于集成测试使用了真实的文件系统.

The only difference between integration and unit tests for this class, is that with unit tests the filesystem mock would be used (class would be fully isolated), while with integration tests the real filesystem is used.

如果您可以将参考文献添加到经典书籍中，或者添加著名行业人士的文章/演示文稿，我将不胜感激，因此我们可以为支持得出的结论提供坚实的基础.

I would appreciate, if you can add the references to classic books, or maybe articles / presentations of well-known industry people, so we can have a really strong ground to support the resulting conclusion.

推荐答案

这里的简短答案是，您可以使用集成"测试来完全测试一个类.不过，更好的问题是应该这样做吗?

The short answer here is yes, you could fully test a class with 'integration' tests. The better question, though, is should you do so?

我认为您太在意单元测试"(没有外部依赖项)和集成测试"(具有这种依赖项)之间的定义差异.测试的目的是使您确信自己的代码始终在工作，同时降低与此相关的成本.所以你的问题

I think you're getting too hung up on the difference in definitions between a 'unit test' (no outside dependencies) and an 'integration test' (has such dependencies). The goal with testing is to give you confidence that your code is working at all times, while keeping the associated costs of having that confidence down. So your question

对于没有这种情况的边缘情况，集成测试是否足够充分 复杂类，主要负责处理文件系统 (DB等)?

Is integration testing fully enough for an edge case of having not a complex class, which has main responsibility to work with a filesystem (DB, etc.)?

有点不完整.

在我们的讨论中，区分单元"和集成"的最有用的部分是:单元测试更易于编写，维护和运行，而且更便宜.

The most useful part of that distinction between 'unit' and 'integration' for our discussion is this: unit tests are easier and cheaper to write, maintain, and run.

要编写单元测试，您只需要知道代码.如果单元测试失败，那么您知道这是由于代码更改所致.编写集成测试需要设置依赖项，例如创建具有特定内容的文件，将行插入数据库等.如果集成测试失败，则可能是您的代码，也可能是您的依赖项.由于这些原因及其他原因，集成测试的创建，维护和运行更加复杂，因此成本较高.

To write a unit test, you just need to know the code. If a unit test fails, you know it's because of changes to the code. Writing an integration test requires setting up dependencies, eg creating files with specific contents, inserting rows in to a database, etc. If an integration test fails, it could be your code, or it could be your dependencies. For these reasons and others, integration tests are more complex, and therefore expensive, to create, maintain and run.

增加的费用应促使开发人员将封装业务逻辑的类与处理与外部系统交互的类分开，以最大程度地减少所需的集成测试次数.可以使用更便宜的单元测试来测试业务逻辑.

That increased expense should push the developer to separate classes encapsulating business logic from classes that handle interaction with outside systems, in an effort to minimize the number of integration tests required. The business logic can be tested with unit tests, which are cheaper.

修改

您的类可能具有本身很复杂的复杂逻辑，因为它必须处理基础外部依赖项(即所讨论的文件系统)中的复杂行为.在那种情况下，对文件系统进行模拟本身可能会很困难，并且 仅使用正确设置的文件系统并编写集成"测试可能会更便宜/更容易.

It is possible that your class has complicated logic that itself is complicated because it has to handle complicated behavior in the underlying external dependency (ie, the file system in question). In that case, mocking the file system may be quite difficult in itself, and it may be cheaper/easier to just use a properly set up file system and write 'integration' tests.

要牢记的重点是您要实现的目标:以可接受的成本获得信心.如果集成"测试足够便宜，那就太好了.如果您可以使用单元"测试更便宜地获得相同的置信度，那就更好了.确切的组合取决于手头的问题.

The important point to keep in mind is what you're trying to achieve: confidence at a acceptable cost. If 'integration' tests are cheap enough, great. If you can get the same confidence cheaper using 'unit' tests, even better. The exact mix depends on the problem at hand.

这篇关于除了数据库，文件系统等的集成测试之外，还需要单元测试吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！