如果满足功能测试，单元测试仍然重要吗? [英] Does Unit Tests still matter if Functional Tests is satisfied?

问题描述

简短摘要:

• 单元测试是较小的那些，希望在开发人员看来正确地做点事情.
• 功能测试是指那些期望用户认为正确的测试

如果功能测试已经得到满足，我们还需要进行单元测试吗?

If Functional Tests are already satisfied, do we still need to do Unit Tests?

最有可能(让我们使用Web开发作为上下文)，这是通过使用浏览器通过让其他用户/其他人尝试系统/应用程序查看事情是否正确来实现的.

Most likely (let's use web development as context), this is common by using the browser to see if things are right by letting other users/people try the system/application.

让我们针对边缘情况进行其他测试.

Let us put out other tests like for edge cases.

推荐答案

您是否使用任何指标来确定功能测试是否满意"?

Are there any metrics that you're using to determined if a functional test is "satisfied"?

我认为进行客观的测量以创建基准来比较测试类型是有帮助的，常见的是代码覆盖率.

I feel like it helps to have an objective measurement to create a baseline to compare types of tests, a common one is code coverage.

通过确定代码覆盖范围，可以轻松比较功能测试和单元测试，功能测试是否涵盖与单元测试相同的代码行?如果是这样，那就多余了.

By identifying code coverage it's easy to compare functional tests, and unit tests, does the functional test cover the same lines of code as the unit test? If so than it is redundant.

问题是，这忽略了很多其他问题:

The problem is this ignores a ton of other issues:

• 功能测试是否长时间无法运行?它们难于设置，还是仅在CI中执行?然后在单元测试中复制代码行可能很有意义，这将为开发人员提供快速的反馈.
• 这是POC还是不成熟的项目?功能测试可能会带来最大的收益，因为它们应该能够断言更高级别的用例并从实现细节中抽象出来.当实施细节不确定时，这非常有用
• 代码覆盖率具有误导性，以IO为中心的库(即DB驱动程序)可以通过模拟其依赖关系轻松地实现100％的代码覆盖率.如果在这种情况下使用代码覆盖率比较功能测试和单元测试，我们将缺少测试的多个维度，因为功能测试将行使IO依赖性. (在这种情况下，IMO单元测试实际上是一个很小的值，并且会给IO繁重的代码带来虚假的信心，从而导致集成错误通常会在开发人员的以后几个周期中被发现，而修复这些问题的成本更高
• 您谈到了一些极端情况，功能测试通常会说明几个客户流程.使用功能测试来执行所有极端情况并进行错误处理通常会浪费资源，最终会创建大量难以维护的缓慢测试套件

这篇关于如果满足功能测试，单元测试仍然重要吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！