大型企业通常如何进行单元测试？

《有效的单元测试》是一本非常值得推荐的读物。有需要这本书的，可到文末领取。

你平时是怎么做单元测试的？

面试官心理预期

面试官询问单元测试并非仅仅想了解这一概念，背后可能考察面试者以下三个方面：

1. 对软件工程生命周期的熟悉程度，以及对测试阶段各种方法（包括单元测试、集成测试、冒烟测试等）和其重要性的理解。

2. 面试者是否展现出足够的责任心，明白优秀的测试工作对自身代码负责的重要性。

3. 优秀的单元测试用例也体现了开发者在设计和编码方面的基本素质。

基于以上三点，我们需要思考什么样的单元测试才能被视为有效？

高手回答

整个软件工程的生命周期大致分为以下阶段：

• 需求分析阶段：包括需求调研、设计和评审

• 设计阶段：主要集中在架构设计

• 开发阶段：正式开始编码工作

• 测试阶段：完成编码后，包括：

• 自测：单元测试 -> 集成测试

• 提测：QA 介入集成测试，进行多轮测试

• 发布阶段：QA 完成测试后，可以进行上线，其中包括：

• 预发布：部署到线上环境，QA 进行回归测试，逐步增加流量，观察是否存在异常

• 正式上线：若预发布无问题，则代码正式上线，根据灰度或 A/B 测试策略控制新功能流量比例，经过稳定运行一段时间无异常后，逐步放开全部流量。

我们再深入分析每个阶段发现缺陷的成本，主要指从发现到解决问题所需的人力时间成本：

• 需求分析阶段：如果设计评审发现不合理，可以选择不执行，仅需花费几个小时进行会议讨论。

• 设计阶段：架构设计也需要评审，同样只需要几个小时会议时间。

• 开发阶段：如果前两个阶段没有问题，小型功能修复通常需要几小时，大型功能可能需要几天甚至更长时间，可能导致开发出无效功能，需要重新设计和开发，带来重复劳动的局面。

• 测试阶段：无论是自测还是提测的集成测试，修复一个缺陷意味着重新部署代码，对于大型项目，启动时间可能是分钟级。不论是自测还是提测，修复多个缺陷会阻塞测试进度，多次部署累计的时间成本非常高。而单元测试一个案例通常只需要毫秒或秒级，做好单元测试可以显著提高效率。许多公司非常重视单元测试的覆盖率和有效性，甚至将单元测试纳入持续集成/持续交付流程，仅当所有单测通过才能部署。同时，QA 团队也极为关注阻塞测试进度的情况。

• 发布阶段：通常经过 QA 严格测试后才进入发布阶段，虽然不会出现明显的缺陷，但也不能排除存在问题。某些缺陷可能在实际用户请求或高流量时才会显现，这些越过测试和预发布环境的问题可能会在线上直接暴露。灰度和 A/B 测试的部分目的是将线上问题造成的影响最小化。这也解释了即使在各大互联网公司，仍可能发生事故。这种情况不仅涉及时间成本，严重的缺陷可能带来直接的经济损失和用户流失，一旦程序员出现问题，将成为谈资。因此，许多公司非常重视缺陷漏测率，即测试阶段未发现的问题。

上述内容提到了单元测试的关键要点，以下是编写优质单元测试的方法总结：

如何编写单元测试

1. 单元测试代码与正式代码同等重要，需要清晰层次分明，命名符合实际场景，并且要有适当的注释。可借鉴《代码整洁之道》中的技巧，关键是要确保测试用例易于理解。

2. 不要盲目地追求覆盖率，而是要尽可能覆盖所有可能的场景。

3. 单元测试要保持可用性，纳入持续集成/持续交付流程。如果所有测试用例不能通过，就不允许部署。

4. 确保每次运行测试用例都是确定性的，不依赖外部变化和不确定因素，包括但不限于：

• 随机事件：例如随机数，最好使用模拟(Mock)进行控制；

• IO 操作：无论是磁盘 IO 还是网络 IO（如数据库、外部接口），都需要隔离，最好也进行模拟。

5. 必须包含断言，否则单元测试就失去了意义。不能只是简单地打印结果，人工观察，在运行所有测试用例时很少会花时间检查每一个输出。

6. 验证边界情况和异常情况，这两点经常被忽视。边界条件可能包括：

• 传入错误参数的反应；

• 依赖返回不正确结果的情况。

异常情况包括：

• 外部异常：依赖（内部或外部接口、数据库环境等）抛出异常将如何处理；

• 内部异常：代码本身抛出 RuntimeException 的后果。

7. 正式业务代码应该遵循单一职责原则，高内聚低耦合可使单元测试更简单，测试粒度更细致，覆盖率更高。每个方法或类应只负责一项任务，这样测试用例只需关注当前方法的有效性，而不需要考虑方法之间的调用。每个测试用例也应只关注一件事情。

另一个优秀的策略是采用测试驱动开发（TDD）方法，即先列出所有可能的测试用例，然后再开始实现逻辑代码。这种方式可以快速创建出完备的单元测试集合。值得注意的是，在国内很少有公司采用 TDD 开发模式。

领域驱动设计（DDD）强调明确的边界划分，事件风暴和防腐层的设计为测试驱动开发（TDD）和单元测试提供了良好的基础。领域驱动设计（DDD）中倡导清晰的边界划分，通过事件风暴和防腐层设计，为 TDD 和单元测试提供了有力支持。

前文提到使用 Mock 对象来隔离 I/O 操作和随机事件，当然，Mock 也可以应用于各种依赖关系，比如 Spring Bean 之间的依赖、工具类、各种内部接口的依赖等。Mock 的作用是模拟所依赖的资源，我们可以假定依赖操作是成功或失败的，这样测试只需关注自身代码对依赖产生的响应结果即可。

Java 的单元测试

Java 工程也可以集成 Spock 框架进行单元测试，Spock 使用 Groovy 语言编写测试用例。由于 Groovy 是一种动态语言，非常灵活，非常适合编写简洁的单元测试代码。同时，Spock 不仅局限于模拟（Mock），还提供各种高效的功能（这些是传统 JUnit 和 Mockito 无法实现的）：

1. Spy：可以对部分资源进行模拟，方便地对同一类内相互调用的方法进行模拟和验证。

2. Mock：对依赖资源进行模拟，同时验证依赖资源被调用的次数。例如，测试 Redis 写功能时，可以模拟 Redis 客户端，验证传入方法的参数是否符合预期，以及验证 Redis 写入方法被调用的次数。

3. Stub：对依赖资源进行模拟返回一个结果，不关心调用次数或参数是否匹配预期。

4. 可以直接忽略待验证方法的成员封装级别，可以直接测试私有声明的方法和变量。

5. 基于数据驱动的测试：借助where关键词和数据表格的方式，在一个测试案例中验证要测试的参数和期望返回值的所有可能情况。

6. 可以方便地验证抛出的异常。

7. 与 Spring 集成方便：可以进行 Spring 框架的集成测试，包括对 Spring MVC、Spring Boot 的 HTTP 接口层进行单元测试，无需启动 Web 容器。

所以编写优秀的单元测试代码是卓越程序员的基本修养。因为针对有用户访问和无用户访问的项目，相同的代码甚至在极端用户流量下可能带来截然不同的效果。在面对极端用户流量时，每次修改一行代码上线都如履薄冰。怀着敬畏之心对待每一次上线和线上操作，至关重要。

有效的单元测试：

链接：https://pan.baidu.com/s/174DXtbtAyXiO1VMzDnRtPg?pwd=msyj提取码：msyj

如果失效：请微信搜索【码上遇见你】或+ w714771310留言获取