文章摘要

前言

作者接手了一个已经上线运行的产品，负责后续开发和维护，并尝试将测试驱动开发（TDD）应用于已有产品的工程实践。Kent Beck在其经典著作《测试驱动开发》中提到，为已有工作的代码编写测试是一项困难任务，原因包括代码未按可测标准编写、缺乏测试反馈导致改动风险增加，以及需要打破“无测试反馈”的循环。Kent建议通过结对编程等方式获得反馈，逐步推进测试实践。

现状

作者接手的产品是一个基于RESTful API的服务，缺乏功能级单元测试，但有少量基于Postman的HTTP请求脚本以及开发人员编写的API调用程序。产品的发布测试主要依赖QA团队通过其他业务线产品进行回归测试，以确保改动的稳定性和符合预期。

Todo List

如何快速熟悉并掌握系统？

作者计划通过整理主要业务逻辑范围，形成验证目标场景，并基于这些逻辑编写系统级测试代码。通过断言验证实际反馈与预期结果的一致性，利用单元测试框架（如xunit）跟踪代码，逐步理解系统并构建测试基础。

如何保证添加新功能/修改功能后系统依旧稳定？

通过编写覆盖主要业务逻辑的验证案例，逐步扩展测试范围，构建一张系统“安全网”。这种集成测试虽然运行速度较慢，但能提供可靠反馈，新开发功能则可从功能级单元测试开始，逐步实现TDD实践。

如何保证系统依赖方发生修改后系统依旧稳定？

作者采用“学习测试”模式，在学习第三方API时，通过单元测试框架设定明确的预期输入和输出，为系统集成构建测试“安全网”。这种方法可快速反馈第三方API的改动对系统的影响。

小贴士

作者分享了基于.NET Core开发的一些实用技巧，包括使用内存模拟技术优化测试运行速度和复杂性。例如，利用Asp.Net的TestServer实现内存模拟服务，替换系统关键位置服务以构建测试场景；通过测试替身（如Mountebank或Postman Mock Server）替代复杂第三方服务；针对异步回调场景，通过依赖注入框架和内存队列实现回调数据验证。

总结

测试驱动开发旨在为系统功能构建安全网，降低重构风险并提高开发功能的准确性。作者分享了对已有系统补充集成测试的实践经验，虽成本较高但效果显著。针对不同系统场景，应灵活选择测试方法，践行敏捷实践以提升工作质量。

参考引用

• 《测试驱动开发》
• ASP.NET Core 中的集成测试