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

　　面试官心理预期

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

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

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

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

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

　　高手回答

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

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

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

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

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

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

　　  - 提测：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容器。

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

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

 

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取