【发布时间】：2020-02-01 22:04:18
【问题描述】：
在现实生活中，单元测试不可能有 100% 的代码覆盖率。但是我的同事似乎只喜欢编写单元测试用例和快乐流功能测试。最后，工单被 QA 拒绝，他们不得不再次花费更多时间进行重构。
【问题讨论】：
标签： unit-testing integration-testing code-coverage functional-testing
【发布时间】：2020-02-01 22:04:18
【问题描述】：
不可能说是什么激励了您正在合作的特定开发人员，但单元测试可以是：
- 更快
- 更易于设置/拆除（因为它们往往较少依赖外部资源）
- 因为您可以访问内部，所以更容易编写
- 不那么不稳定（因为他们倾向于较少依赖外部资源）
进行可靠的回归测试很重要，但任何可以编写为单元测试的测试都应该如此。
【讨论】：
在回答您的问题时存在对同事不公正的风险，因为您没有给出具体的代码示例来讨论。因此，您的同事确实有可能像您对单元测试的看法那样过度使用单元测试，但也有可能他们做得正确。
但是，我也观察到，一般来说，有些人试图通过设置简单的规则来管理软件生成工艺的困难（包括测试以及许多其他活动）。由于习惯性规定的规则对一小部分案件有很好的指导作用，因此在规则过于简单化的情况下，需要相当的自信、经验、意志和能力来反对它们。
谈到代码覆盖率，越多越好，对吧？至少很多人一开始是这样想的。在这个阶段，他们甚至可能不知道存在不同的覆盖标准（语句覆盖、分支覆盖……）。他们甚至可能不清楚单元测试与交互测试（集成测试）和子系统测试（组件测试或功能测试）的区别。只有当您获得更多经验并且有兴趣扩展您对测试方法的知识时，您才会学到更多，并且可能在某个时间点了解哪种方法最有益。
但是，即使你达到了这一点，你仍然必须愿意与那些首先制定组织或项目规则的人争论：这些人通常足够多，没有太多的软件实践经验开发自己，如客户或质量保证人员。要让这些人相信他们选择的规则不适合这种情况或其他情况，需要教他们很多东西——这需要一定的努力，如果他们对扩展知识不感兴趣，有时可能完全没用。
但是，即使他们在某些时候同意您的观点并接受在您的情况下例外是可以的，他们也不愿放松或完善规则：通常这些各方将开发人员群体视为一群白痴，只有通过制定严格的规则，才能编写出不会因违反基本规则而出现错误的软件。就像，人们只写很少的单元测试，甚至根本不写单元测试，除非你为每个人设定了一些高测试覆盖率目标。不幸的是，他们的经验证明他们是正确的。
也许上面的那几行似乎有点悲观。解决办法是什么？解决方案是一个认真对待质量并了解软件质量的本质（在您的案例中是测试质量）与满足简单的度量标准或遵循简单的规则根本不同的组织。为了使测试具有高质量，组织必须愿意以正确的方式投资于测试，确保各方了解不同类型测试的各自目标，并让开发人员和测试人员就测试用例、测试代码的方式进行争论“规则驱动的软件开发”需要转化为“理解驱动的软件开发”，但是这样的转化很难。
【讨论】：