单元测试策略,理想代码覆盖基线

Question

从单元测试和代码覆盖的角度来看,关于XCode7和Swift 2.0实际体验的信息仍然不多.

虽然有大量的教程和基本的操作指南可供使用,但我想知道不同iOS团队的经验和典型的覆盖率统计数据实际上是试图为他们发布的iOS/Swift应用程序实现合理的覆盖范围.我特别想知道这件事:

1)虽然代码覆盖百分比不代表代码库的整体质量,但这是否被用作团队的基本指标？如果没有,评估代码库质量的另一种可衡量的方法是什么？

2)对于更强大的应用程序,您目前的代码覆盖百分比是多少？(只是fyi,我们现在的代码库很难超过50%)

3)你如何测试如下:

• App生命周期,AppDelegate方法
• 任何与推送/本地通知,深层链接相关的代码
• 防御性编程实践,各种心态(几乎不可重复)的安全防护,异常处理等.
• 动画,过渡,自定义控件(CG)等的渲染
• 可能包含任何其他逻辑的弹出窗口或警报

我理解上面的一些更多是实际UI测试的主题,但它让我想知道:

• 是否有合理的方法从UTs的角度进行上述测试？我们是否应该尝试使用UT来满足整个代码库的任意最小代码覆盖百分比,还是应该根据应用程序的代码库来定义合理可实现的覆盖率？
• 为了获得更高的覆盖率,使代码库更加不灵活是否合理？(我不是在谈论一个医疗应用程序,这里的生命将受到威胁)
• 除了使用UI测试之外,是否有任何关于测试上述所有内容的良好实践？

期待富有成效的讨论.

Answer 1

你确实问了一个很大而且很好的问题。虽然你的问题包括：

我想知道不同 iOS 团队的经验和典型覆盖率统计数据是什么......

我认为这个问题与语言/操作系统无关。当然，某些语言和平台比其他语言和平台更易于进行单元测试。因此，有些单元测试的成本更高（与其他形式的自动化/编码测试相比）。我认为您正在寻找一个成本/效益方程来最大限度地提高生产力。软件开发过程的乐趣啊。

跳到最后给你快速的声音抓取答案：

您应该对您想要运行且适合单元测试的所有代码进行单元测试。

那么现在为什么要强调单元测试......

什么是单元测试？

开发社区中的语言已经被破坏，所以请耐心等待。单元测试只是自动化测试的一种。其他包括自动验收测试、应用程序测试、集成测试和组件测试。这些都测试不同的东西。他们有不同的目的。

然而，当我听到单元测试时，我脑海中浮现出两件事：

1. 什么是单元测试？
2. 作为 TDD（测试驱动开发）的一部分？

TDD 是指在编写代码之前先编写测试。当您编写一个测试来编写一个语句，然后编写另一个测试时，这是一个非常低级的编码实践/过程（XP - 极限编程）。很大程度上是一种编码实践，但不是应用程序/需求实践，因为它是编写执行您想要的代码的代码，而不是满足产品要求的代码（天哪，我觉得要点丢失了）。

根据我的经验，编写代码然后进行单元测试是有趣的、短期的团队建设，但效率不高。当然会发现一些缺陷，但不是很多。TDD 可以带来更好的“健康”代码。

我的观点是单元测试是：

1. 自动化/编码测试的子集。
2. 是编码过程的一部分。
3. 关于代码健康（可维护性）。
4. 是否注意到证明您的应用程序有效（落点的声音）。

为什么全部？

如果您的团队在没有单元测试的情况下始终提供零缺陷软件（ZDFD 是真实且可实现的..但这是一个平坦的地球讨论），那么这是无稽之谈，您不会在这里提出任何问题。

团队将单元测试作为其编码过程的一部分的唯一正当理由是提高生产力。如果所有团队成员都致力于提高团队生产力，那么唯一的问题就是确定哪些代码可以从单元测试中受益。这就是一切的背景。

我认为说明这一点的最简单方法是列出我不进行单元测试的类型：

• 工厂 - 它们仅实例化类型。
• 构建器/编写（IoC） - 与工厂相同 - 没有域逻辑。
• 第三方库 - 我们将文档中的第三方库称为第三方库。如果您想测试这些，请使用集成/组件测试。
• 循环复杂度为 1 - 类型的每个方法的 CC 均为 1。即没有条件。单元测试不会告诉你任何有用的信息，同行评审更有用。

实际的答案

我的团队期望对所有应进行单元测试的新代码实现 100% 的单元测试覆盖率。这是通过归因不符合单元测试标准的代码来实现的。所有代码都必须经过代码审查，并且属性必须特定于上面列出的原因选项。 - 简单的。

一个很长的答案，也许不容易消化，也不是人们想听到的。但是，根据长期的经验，我知道这是可以带来最佳盈利能力的最佳答案。

发表评论

我的回答是针对问题的单元测试方面。至于防御性编程和其他实践，TDD 是一个通过让做错事变得更加困难来缓解这种情况的过程。但是构建系统静态代码分析工具可以帮助您在进行同行评审之前捕获这些内容（它们可能会因新问题而导致构建失败）。看看其他的，比如 SonarQube、Resharper、CppDepend、NDepend（是的，依赖于语言）。