测试周刊004: 单元测试和接口测试用例将成为标配
马上就到端午假期了。
今天在电梯听到两位女士的对话，大概的意思是一位认为只有一天的假期有点不太过瘾，而另一位觉得假期归来以后上 4 休 2 已经是非常划算了。
反正我是同意后者的。
观点
AI 将使得单元测试和接口测试成为标配
前些天 deepseek 发布了新模型，该模型在代码能力上有了较大的提升。
有人尝试之后表示模型不仅可以正确实现编码需求，还可以在生成代码的同时给出完整的单元测试用例。
今后将有越来越多的代码会由 ai 实现，而我们可以非常自信的要求 ai 在给出实现的同时，给出完成的单元测试用例和接口测试用例。
因此在不久的将来，单元测试用例和接口测试用例将会成为增量代码的标配了吧。
测试同学可能不需要人人都会写单元测试用例了，但是学会看懂测试用例，并用测试思维来对用例进行评审，反而是更实用的技能了。
从质量保证到集成保证
传统的"质量保证"概念存在两个极端问题：
- 过度依赖 QA：认为 QA 团队独自负责产品质量，其他团队可以推卸责任
- 完全取消 QA：认为每个工程师都应该"拥有质量"，但缺乏系统级验证
作者认为传统的"质量保证"（QA）概念存在误导性，因为质量应该是每个团队的共同责任，而不是 QA 部门的专属职责。
他提出将 QA 重新定义为"集成保证"（Integration Assurance），专注于验证现代软件系统中多个服务和组件之间的协同工作，就像苹果公司需要确保 iPhone 各个供应商的零件能完美集成一样。
这个角色类似足球比赛中的守门员——不是唯一的防线，但是防止问题到达用户的最后屏障，同时帮助发现系统级的协调问题和集成风险，而 AI 测试工具应该主要由这个集成保证团队来使用，以确保从全局视角进行有效的端到端验证。
自动化测试
有效的软件测试需要通过测试替身（Test Doubles）来隔离被测系统，从而编写可控、可靠的单元测试
https://medium.com/@raissa.puti/behind-the-green-check-a-guide-to-test-doubles-7199be3b08c2
作者认为，真正的测试不仅仅是检查功能是否正常运行，而是要通过 Dummy、Stub、Spy、Mock、Fake 等不同类型的测试替身来替代真实的外部依赖（如 API、数据库、时间服务等），这样可以：
- 控制测试环境和输入数据，
- 验证特定的交互行为，
- 避免依赖不稳定的外部服务
- 提高测试速度和可靠性。
作者以自己的 React 项目 SiNgawas 为例，展示了如何在前端测试中应用这些概念，同时分享了借助 AI 工具来改进测试设计的经验。文章强调，好的测试应该专注于验证有意义的行为，而不是简单地检查 UI 渲染，通过合理使用测试替身可以让每个测试都有明确的目的和可预测的结果。
