单元测试程序不应该做什么

Question

这个问题是关于它在多大程度上进行单元测试。

我一直在编写一个典型的程序，用XML消息中的信息更新数据库。我想到了它需要的单元测试。程序根据复杂的规则插入或更新记录，从而产生许多不同的情况。起初，我决定针对每个案例测试以下几个条件：

• 添加的必要记录数
• 正确填写插入和更新记录的字段
• 没有记录存在，但与上传数据无关的内容已更改

在我看来，第三种测试真的很有意义。但很快我发现这并不容易实现，因为你实际上需要对数据库进行快照，然后将其与修改后的数据库进行比较。我很快就开始厌倦了我需要为不同的数据库修改案例编写这样的测试，而这些测试在规范和生产代码设计方面没有多少价值和信息。

然后我想，也许，我测试的太多了？如果没有，那么如果我测试程序不会修改不相关的记录，那么为什么我不测试它呢：

• 不修改其他数据库
• 不删除磁盘上的文件
• 不发送电子邮件给Santa Klaus？

我完全糊涂了绘制边界的地方。你会在哪里画它？

更新

我在答案中阅读了许多有用的提示并将其标记为解决方案，因为它对我有更多有用的想法，但我仍然不清楚如何正确测试数据库更新。测试程序不会改变太多有意义吗？如果是这样，那么有多彻底？

Answer 1

您在测试停止有用的位置画线，不再告诉您有关 代码的信息。

知道您的软件不向圣诞老人发送电子邮件是否有用？不。那就不要测试了。

知道数据访问层正在做正确的事情是有用的 - 正确的更新正在发生。

Answer 2

更容易测试它应该做什么，然后它应该做什么。一些例外：

• 安全性：具有“本地管理员”访问权限的用户不应该看到“全局管理员”页面。
• 边缘情况：2月30日未解析为2011-02-30
• 您的规格/分析中明确显示的内容“用户可以查看平均评分，但不能查看单个记录”。

Answer 3

如果一个人拥有无限的时间和资源（没有更好的与他们相关:-)，那么测试所有可能的会很好（尽管仍然相当无聊）测试。然而，我们生活在现实生活中，我们有时间和资源压力，因此我们必须优先考虑我们的测试工作。 Kent Beck很好地总结为“测试可能会破坏的所有东西”。

请注意，这在某种程度上也适用于集成/系统/验收测试，但区别在于单元测试是白盒测试，因此您应该知道两者

• 您的代码应该做什么，以及
• 你实际所写的内容。

这使您可以将单元测试工作集中在实际问题上。您的方法是否将数据写入输出流？是？那么测试那里（不）写的东西是完全合理的。你的方法是否做了与邮件有关的事情？没有？然后没有点测试它不向圣诞老人发送邮件。

系统/验收测试的不同之处在于

• 它们是黑盒测试，因此测试者（应该）不会对程序的实际实现方式做出任何假设，并且
• 他们测试了一个完整的复杂程序，其中不同部分以意外（可能不需要的）方式交互的可能性更大。

因此，建立更广泛的测试网络，测试更多“疯狂”场景并验证程序应该不做的更多事情更有意义。

Answer 4

我认为一个好的单元测试是测试函数的所有代码行以及它涵盖的所有需求/用例。

对于简单函数，它通常意味着测试正确的功能及其处理的错误，并验证它是否是预期的行为。

我会在那里划一行进行单元测试，我也会记住你有的其他问题，并在系统或集成测试中处理它们。这意味着在任意数量的场景中测试应用程序，然后检查数据库是否仍然正确，没有文件被删除，圣诞老人没有收到任何电子邮件。 你可以测试任何数量的可能性，当然你测试的事情越不合理，浪费的时间就越多。