测试先行

最近在看了《测试驱动开发》一书，对其中的观点深以为然。

会想起之前在好说工作的日子，由于人员紧缺，但又急需新功能上线，从而刺激用户的增长和提高用户的粘性。那段时间的开发可以称之为昏天黑地，经常一周就是一两个大功能上线，也不会专门去写一些测试，功能跑通就上线，也由此埋下了祸端。

2023年底，由于前期设计不足和需求，导致服务无法支撑较大用户量的同时聊天。架构优化由此开始，但多走一步就是地狱。

没有测试，没有历史需求文档，在这种情况下拆解服务，没走一步都是万丈深渊。过程也可谓曲折：

• 找历史需求单子
• 找产品
• 啃五花八门的代码
• 找相关的开发同学
• 测试提交大量bug单
  。。。
  好在最后，磕磕绊绊的完成了微服务的拆分。后来，就开始留意代码的测试。时间一长，发现其却又存在的意义：一方面完善的测试可以更好的辅助开发，降低开发的心智成本，不用随时担心会不会因为修改什么导致已有功能的损坏。二来，轻装前行，不必每次都需要手动测试相关功能。

目前个人形成的工作流如下：

1. 在开发时间合理的情况下：

   1. 完成功能测试，一来可以帮自己梳理业务逻辑，二来可以更好的和产品沟通业务逻辑。
   2. 开发代码
   3. 完成单元测试。
   4. 根据业务持续迭代相关测试。

2. 如果时间紧张：

   1. 优先完成功能，并将需要测试的部分又TODO标记
   2. 功能完成后，根据时间和测试同时进行测试，并将测试反馈的问题补充到测试中
   3. 定期检测代码中的TODO项，进行完善。

3. 善用AI工具

4. 根据经验制作地代码工具帮助自己写测试。

5. 后续有优化回来补充。

这套工作流在我目前的工作中，确实提供了不少便利，也希望这篇文章能对此时的你有所帮助。