一个测试用例应该涵盖多少? [英] How much should one TestCase cover?

问题描述

直到现在我从来没有写过一个合适的测试，只有测试成功后我会处理的小程序.我在网上浏览了 Python 的 unittest 模块和教程，但有些东西我不清楚.

I've never written a proper test until now, only small programs that I would dispose of after the test succeeded. I was looking through Python's unittest module and tutorials around the web, but something's not clear to me.

一个TestCase应该覆盖多少?我在网络上看到过一些示例，其中包含只有一种方法的 TestCase 类，以及测试几乎所有可用功能的类.

How much should one TestCase cover? I've seen examples on the web that have TestCase classes with only one method, as well as classes that test almost the entire available functionality.

就我而言，我正在尝试为简单的布隆过滤器编写测试.您认为我应该如何组织我的测试用例?

In my case, I'm trying to write a test for a simple bloom filter. How do you think I should organize my test cases?

推荐答案

简单来说:一个单元测试应该覆盖你程序的单一功能.这就是所有要说的.这就是它们被称为单元测试的原因.

To put it simple: one unit test should cover single feature of your program. That's all there is to say. That's why they're called unit tests.

当然，我们对功能的理解可能会有所不同.考虑程序中可能会中断或无法按预期工作的最小部分.考虑您的代码的业务需求.您希望专用单元测试涵盖这些部分.

Of course, what we understand by feature may vary. Think about smallest parts of your program that might break or not work as expected. Think about business requirements of your code. Those are parts that you want each to be covered by dedicated unit test.

通常，单元测试是小的、孤立的和原子的.它们应该易于理解，它们应该彼此独立地失败/通过，并且应该快速执行.正确的单元测试的一个很好的迹象是单一断言——如果你发现自己写了更多，你可能测试太多了，这表明你需要对给定功能进行多个测试.然而，这并不是一个严格的规则——涉及的代码越复杂，单元测试就越复杂.

Usually, unit tests are small, isolated and atomic. They should be easy to understand, they should fail/pass independently from one another, and should execute fast. Fairly good indication of proper unit tests is single assertion - if you find yourself writing more, you probably test too much and it's a sign you need more than one test for given feature. However, this is not a strict rule - the more complex code is involved, the more complex unit tests tend to be.

在编写测试时，很容易拆分您的代码功能并测试这些分离的部分(这应该让您了解测试的原子性).例如，如果您有一个验证输入然后调用服务并最终返回结果的方法，您通常希望涵盖所有三个(验证、调用、返回)步骤.

When writing tests, it's easy to split your code functionality and test those separated parts (this should give you the idea of atomicity of your tests). For example, if you have a method that verifies input then calls a service and finally returns result, you usually want to have all three (verify, call, return) steps covered.

这篇关于一个测试用例应该涵盖多少?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！