何时使用单元测试？

Question

我理解如何实现单元测试,我只是在努力弄清楚何时使用它们.

假设我有一个基本的提醒应用程序.用户可以添加/编辑/删除提醒并在桌面视图中查看它们.我想为应用程序的哪些部分设置单元测试？

Answer 1

理想的世界答案会说你编写的每一行代码都应该经过单元测试.

但是让我们暂时忘掉这一点,然后回到现实世界.为重要的代码编写测试并拥有另一道防线是值得的.换句话说,测试构造函数是否仅仅为一个字段赋值？很可能不是.是否值得单元测试解析器从客户端提供的复杂XML中提取帐户数据？可能是.

这种差异来自哪里？两个主要原因:

• 构造函数代码不太可能遭受不可预测的更改(相对于不断发展的解析器代码,以满足不断变化的需求/优化/重构)
• 构造函数代码相当简单,你已经多次编写过这样的代码,测试可能无法为你发现问题提供巨大的优势; 快速浏览一下这些代码,你很可能会知道发生了什么(与复杂的XML解析器代码相比)

为什么要区分？为什么测试这个而不是那个？简单地测试一切都不容易(正如理想的世界答案所暗示的那样)？

不会.由于时间和金钱的限制.编写代码需要两者.并且只有一些人愿意为你的产品支付一定数量的钱,就像他只有一定的时间等待它交付一样.有些测试根本不值得(再次,构造函数代码示例).请记住,单元测试不能免受 收益递减的影响(测试覆盖80%的代码库可能需要额外20%的开发时间,以后节省20%的时间用于调试/维护,而另外10%的时间可能会耗费两倍的时间但收益少得多).

再说一遍,你可能想问"线路在哪里？" 你什么时候决定"好的,不需要对这段代码进行单元测试"？不幸的是,这种判断伴随着经验.编写代码,阅读代码,了解其他人(可能是更有经验的开发人员)做和学习的内容.

如果我要提供几个通用建议(单元测试的内容),那些将是:

• 从业务/域逻辑代码开始
• 确保测试所有类型的转换器/解析器/计算器(这些都很容易测试,往往会因为需求或重构的变化而改变),并且其本质上容易出错)
• 避免测试简单的单线方法,除非一条线在某种程度上是至关重要的
• 为你发现的bug编写测试(并保留它们!)
• 不要盲目追随"好的代码必须有99.99%的测试覆盖率"的魔幻童话
• 在programmers.stackexchange.com 上阅读有关主题的问题 通常可以为您提供解决问题的不同视角

Answer 2

假设您将提醒存储在某个地方，也许是在 plist 中。您可以编写一个单元测试来生成 Reminder 对象、存储它、检索数据，最后生成可用的 Reminder 类对象。

这样你就知道了几件事：

答：您的提醒生成正在运行

B：您存储数据的方法有效

C：从数据到提醒对象正在工作

但是，您不应期望能够对应用程序的实际“功能”进行单元测试。例如触摸事件或导航控件。这些应该留给验收测试，这是一个完全不同的讨论。