我了解如何实现单元测试，我只是在努力弄清楚何时使用它们。
假设我有一个基本的提醒应用程序。用户可以添加/编辑/删除提醒并在表格视图中查看它们。我想为应用程序的哪些部分设置单元测试？
理想世界答案会说每行您编写的代码应该经过单元测试。
但让我们暂时忘记这一点，然后回到真实世界。为重要且具有以下特征的代码编写测试另一条防线是值得的。换句话说，测试仅将值分配给一个字段的构造函数是否有意义？很可能不会。是否值得对解析器从客户提供的复杂 XML 中提取帐户数据进行单元测试？可能是。
这种差异从何而来？两个主要原因：
- 构造函数代码不太可能遭受不可预测的更改（与不断发展的解析器代码以满足不断变化的需求/优化/重构）
- 构造函数代码相当简单，并且您已经多次编写此类代码，测试可能不会为您提供发现问题的巨大优势；快速浏览一下这样的代码，您很可能就能知道发生了什么（相对于复杂的 XML 解析器代码）
为什么要做这样的区分？为什么测试这个而不测试那个？简单地测试所有内容不是更容易吗（如理想世界答案会建议）？
不，因为时间和金钱限制。编写代码需要both。人们愿意为你的产品支付一定数量的钱，就像他等待产品交付的时间也只有一定数量一样。有些测试根本不值得（再次，构造函数代码示例）。请记住，单元测试不能幸免收益递减 http://en.wikipedia.org/wiki/Diminishing_returns（80% 的代码库被测试覆盖可能需要额外 20% 的开发时间，然后节省 20% 的调试/维护时间，而另外 10% 的时间可能会增加两倍，但收益却要少得多）。
再次，你可能想问“线在哪里？”你什么时候决定“好吧，这段代码的单元测试并不是真正需要的”？不幸的是，这种判断是有经验的。编写代码、阅读代码、看看其他人（可能更有经验的开发人员）做了什么并学习。
如果我要给出一些通用建议（单元测试什么），这些将是：
- 从业务/领域逻辑代码开始
- 确保测试所有类型的转换器/解析器/计算器（这些相当容易测试，往往会经常更改[由于需求变化或重构]并且本质上容易出错）
- 避免测试简单的一行方法，除非这一行在某些方面至关重要
- 为您发现的错误编写测试（并保留它们！）
- 不要遵循魔法童话“好的代码必须有99.99%的测试覆盖率” blindly
- reading 问题 https://softwareengineering.stackexchange.com/questions/159964/how-big-does-my-project-need-to-be-for-me-to-unit-test-it on topic https://softwareengineering.stackexchange.com/questions/158052/are-unit-tests-really-that-useful at 程序员.stackexchange.com http://programmers.stackexchange.com通常可以给你不同的视角来解决问题
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
