何时使用单元测试？ [英] When to use unit tests?
问题描述
我理解如何实现单元测试，我只是在努力弄清楚何时使用它们。
I understand how to implement unit tests, I'm just struggling figure out when to use them.
假设我有一个基本的Reminders App。用户可以添加/编辑/删除提醒并在tableview中查看它们。我想为应用程序的哪些部分设置单元测试？
Let's say I have a basic Reminders App. A user can add/edit/delete reminders and view them in a tableview. What parts of the app would I want to set up unit tests for?
推荐答案
理想世界回答会说你写的代码的每一行应该进行单元测试。
Ideal world answer would say that every line of code you wrote should be unit tested.
但是让我们暂时忘记这一点然后再回到现实世界。编写重要且具有另一道防线的代码的测试是值得的。换句话说，测试构造函数是否仅仅为一个字段赋值？很可能不是。是否值得单元测试解析器从客户端提供的复杂XML中提取帐户数据？可能是的。
But let's forget about that for a moment and move back to real world. Write tests for code that is important and having another line of defense is worth it. In other words, does it make much sense testing constructor that simply assigns value to one field? Most likely not. Is it worth to unit test parser extracting account data from complex XML your client provides? Probably yes.
这种差异来自哪里？两个主要原因：
Where does this difference comes from? Two major reasons:
- 构造函数代码遭受不可预测的更改的可能性较小（与发展很快相比解析器代码以满足不断变化的需求/优化/重构）
- 构造函数代码相当简单，你已经多次编写过这样的代码，测试可能无法为你发现问题提供巨大的优势;快速浏览一下这些代码，你很可能会知道发生了什么（与复杂的XML解析器代码相比）
- it's less likely that constructor code will suffer from unpredictable changes (vs. much-evolving parser code to meet up with changing requirements/optimizations/refactorings)
- constructor code is fairly simple and you've wrote such code many times already, tests might not offer you huge advantage in spotting issues; quick glance at such code and you'll be most likely able to tell what's going on (vs. complex XML parser code)
为什么做出区分？为什么测试这个而不是那个？简单地测试所有内容会不会更容易（因为理想世界答案会建议）？
Why making the distinction? Why testing this and not that? Wouldn't it be easier to simply test everything (as ideal world answer would suggest)?
否。因为时间和金钱限制。编写代码需要两个。并且只有一些人愿意为你的产品支付一定数量的钱，就像他只有一定的时间等待它被交付一样。有些测试根本不值得（再次，构造函数代码示例）。请记住，单元测试不能免受收益递减的影响（测试可能包含80％的代码库）需要额外20％的开发时间，以后节省20％的时间用于调试/维护，而另外10％的时间可能会花费两倍的时间而产生更少的收益）。
No. Because of time and money constraints. Writing code takes both. And there's only certain amount of money somebody is willing to pay for your product just as there's only certain amount of time he's going for wait for it to be delivered. Some tests are simply not worth it (again, constructor code example). Remember that unit tests are not immune to diminishing returns (having 80% code base covered with tests might take extra 20% development time and later save 20% time spent on debugging/maintenance, while going for another 10% might be twice as time consuming yet yield much lesser gains).
同样，你可能想问哪里有线？你什么时候决定好的，不需要对这段代码进行单元测试？不幸的是，这种判断伴随着经验。编写代码，阅读代码，看看其他人（可能是更有经验的开发人员）做和学习的内容。
Again, you probably want to ask "Where's the line?" When do you decide "Ok, unit tests for this piece of code are not really needed"? Unfortunately, this kind of judgement comes with experience. Write code, read code, see what others (possibly more experienced developers) do and learn.
如果我要提供一些通用建议（什么是单位测试），那些将是：
If I were to give couple of generic advises (what to unit test), those would be:
- 从业务/域逻辑代码开始
- 确保测试所有类型的转换器/解析器/计算器（这些都很容易测试，往往会因为不断变化的要求或重构而改变），并且其本质上容易出错）
- 避免测试简单的单线方法，除非那条线在某种程度上是至关重要的
- 为你发现的bug编写测试（并保留它们！）
- 不要跟随好的代码必须有99.99％的测试覆盖率盲目的魔法童话
- 阅读问题 programmers.stackexchange.com 上，52 / are-unit-tests-really-useful-useful> on topic 经常可以给出你有不同的视角来解决问题
- start with business/domain logic code
- make sure to test all kind of converters/parsers/calculators (those are fairly easy to test, tend to change often [either due to changing requirements or refactorings] and by their nature are error prone)
- avoid testing simple one-liner methods, unless that one line is crucial in some way
- write tests for bugs that you discover (and keep them!)
- don't follow magic fairy-tales of "good code must have 99.99% test coverage" blindly
- reading questions on topic at programmers.stackexchange.com can often give you different perspective to approach problems
这篇关于何时使用单元测试？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
