您应该使用单元测试来测试什么？

#1 楼

到目前为止，我的个人理念是：


测试所有可能的常见情况。这将告诉您进行某些更改后代码何时中断（我认为这是自动化单元测试的最大好处）。
测试一些您认为可能会异常复杂的代码的极端情况出现错误。
只要发现错误，就在修复它之前编写一个测试用例以掩盖它。
每当有人有时间杀人时，向不太重要的代码中添加边缘案例测试。

#2 楼

迄今为止，在众多答案中，没有人涉及等效划分和边界值分析，这是眼前问题的重要考虑因素。
所有其他答案虽然很有用，但都具有质性，但有可能-最好-在这里要定量。 @fishtoaster提供了一些具体的准则，只是在测试量化的范围内进行了偷看，但是等效分区和边界值分析使我们可以做得更好。

在等效分区中，您将所有可能的输入集划分为根据预期结果进行分组。来自一组的任何输入都将产生等效的结果，因此这些组称为等效类。 （请注意，相等的结果并不意味着结果相同。）作为一个简单的示例，请考虑一个程序，该程序应将小写ASCII字符转换为大写字符。其他字符应进行身份转换，即保持不变。这是对等类的一种可能细分：

| # |  Equivalence class    | Input        | Output       | # test cases |
+------------------------------------------------------------------------+
| 1 | Lowercase letter      | a - z        | A - Z        | 26           |
| 2 | Uppercase letter      | A - Z        | A - Z        | 26           |
| 3 | Non-alphabetic chars  | 0-9!@#,/"... | 0-9!@#,/"... | 42           |
| 4 | Non-printable chars   | ^C,^S,TAB... | ^C,^S,TAB... | 34           |

最后一列报告了测试用例的数量（如果您将它们全部枚举）。从技术上讲，按照@fishtoaster的规则1，您将包括52个测试用例-上面给出的前两行的所有测试用例都属于“普通用例”。 @fishtoaster的规则2还将添加上面第3行和第4行中的部分或全部。但是对于等效分区测试，每个等效类中的任何一个测试用例就足够了。如果选择“ a”或“ g”或“ w”，则您正在测试相同的代码路径。因此，您总共有4个测试用例，而不是52个以上。

边界值分析建议进行一些细化：实质上，这表明并非等效类的每个成员都相等。也就是说，边界值本身也应被认为值得进行测试。 （对此，一个简单的理由就是臭名昭著的“一个接一个”错误！）因此，对于每个等效类，您可以有3个测试输入。查看上面的输入域-并具有一些ASCII值的知识-我可能会想到这些测试用例输入：

| # | Input                | # test cases |
| 1 | a, w, z              | 3            |
| 2 | A, E, Z              | 3            |
| 3 | 0, 5, 9, !, @, *, ~  | 7            |
| 4 | nul, esc, space, del | 4            |

（您一旦获得超过3个边界值建议您可能需要重新考虑您的原始等价类描述，但这非常简单，以至于我没有再去修改它们。）因此，边界值分析使我们仅涉及17个测试用例-完全覆盖的信心很高-与进行详尽测试的128个测试用例相比。 （更不用说组合运算法则表明穷举测试对于任何实际应用都是根本不可行的！）

#3 楼

我的意见可能不太受欢迎。但是我建议您在进行单元测试时比较经济。如果单元测试太多，那么您很可能最终会花费一半或更多的时间用于维护测试，而不是进行实际的编码。

我建议您为感觉不好的东西编写测试肠道或非常关键和/或基本的事物。 IMHO单元测试不能替代良好的工程和防御性编码。目前，我正在从事一个或多或少无法使用的项目。它确实很稳定，但是很难重构。实际上，一年内没有人碰过此代码，它所基于的软件堆栈已有4年的历史。为什么？准确地说，因为它充满了单元测试，所以：单元测试和自动化的集成测试。 （是否听说过黄瓜之类的东西？）这是最好的部分：这个（尚未）无法使用的软件是由一家公司开发的，该公司的员工是测试驱动开发领域的先驱。 ：D

所以我的建议是：开发基本骨架后开始编写测试，否则重构会很痛苦。作为为他人开发的开发人员，您永远不会一开始就满足需求。
请确保可以快速执行单元测试。如果您有集成测试（例如黄瓜），可以花一些时间来确定。但是，请相信我，长时间运行的测试并不有趣。 （人们会忘记C ++变得不那么受欢迎的所有原因...）
将这些TDD内容留给TDD专家。
是的，有时您专注于边缘情况，有时则关注常见情况，取决于您对意外情况的预期。尽管如果您始终希望遇到意外情况，则应重新考虑工作流程和纪律。 ;-)

#4 楼

如果您首先使用“测试驱动开发”进行测试，那么您的覆盖范围将达到90％或更高，因为如果不先为它编写失败的单元测试，就不会添加功能。

如果您要在事后添加测试，那么我不建议您得到迈克尔·费瑟斯（Michael Feathers）的《有效使用旧版代码》的副本，并查看一些在代码中添加测试和重构方法的技巧。您的代码以使其更具可测试性。

#5 楼

如果您开始遵循“测试驱动开发”实践，则它们将指导您完成该过程，并知道要进行哪些测试。一些开始的地方：
测试首先出现
永远不要在编写测试之前编写代码。请参阅Red-Green-Refactor-Repeat以获得解释。
编写回归测试
每当遇到错误时，请编写一个测试用例，并确保其失败。除非可以通过失败的测试用例重现错误，否则您还没有真正找到它。
红色-绿色-重构-重复
红色：首先，针对要尝试的行为编写最基本的测试实施。将这一步想像为编写一些示例代码，这些示例代码使用您正在使用的类或函数。确保它编译/没有语法错误并且失败。这应该很明显：您尚未编写任何代码，所以它一定会失败，对吧？在这里要了解的重要一点是，除非您看到测试至少失败一次，否则您将无法确定测试是否通过，是由于某种虚假原因而您做了某些事情。
绿色：编写最简单，最愚蠢的代码，使测试真正通过。不要试图变得聪明。即使您看到有明显的边缘情况，但测试已考虑在内，也不要编写代码来处理它（但请不要忘记边缘情况：稍后将需要它）。这个想法是，每个代码段，每个if，每个try: ... except: ...都应由一个测试用例来证明。该代码不必优雅，快速或优化。您只希望测试通过。
重构：清理代码，获取正确的方法名称。查看测试是否仍然通过。优化。再次运行测试。
重复：您还记得测试没有涵盖的边缘情况，对吗？所以，现在是重要时刻。编写一个涵盖这种情况的测试用例，观察它是否失败，编写一些代码，查看它是否通过，然后进行重构。
测试您的代码
您正在处理某些特定的代码，而这正是您要测试的内容。这意味着您不应测试库函数，标准库或编译器。另外，请尝试避免测试“世界”。这包括：调用外部Web API，一些数据库密集型内容等。只要您可以尝试对其进行模拟（使对象遵循相同的接口，但返回静态的预定义数据）。

#6 楼

对于单元测试，首先要测试它是否可以完成其预期的工作。那应该是您写的第一种情况。如果设计的一部分是“如果传入垃圾将引发异常”，也应进行测试，因为这是设计的一部分。

首先。当您获得进行最基本的测试的经验时，将开始学习这是否足够，并开始查看代码中需要测试的其他方面。

#7 楼

基本的答案是“测试所有可能破坏的东西”。

有什么太容易破坏的东西？数据字段，死灵属性访问器和类似的样板开销。

当然，您的里程数-和您的工作环境的实践-可能会有所不同。