第一步：防护网

为了保证对外暴露的 API 好的 ，即我的重构不影响 API 的使用方，我们需要设计一个合适的防护策略。

在设计的时候，我们采用的是测试金字塔来帮助我们搭建测策略。我们会从下（单元测试）向上（集成测试）一步步搭建测试策略。

而当我们重构的时候，我们则是自顶向下设计防护策略。常见的测试策略有

考虑到测试即文档，在实现实现的时候，会配合一些支持自然语言描述的框架，如：

为了与运行客户端一配合，我们还需要有底层 API 来控制浏览器、客户端应用：

关于 APP 测试方案，可以参考我之前写的《【架构拾集】移动应用的自动化测试（BDD 方式）》

根据现有的 E2E（端到端）/集成测试框架的架构，我画了一个大致的测试策略分层架构图：

选择适合你们团队的测试架构，然后编写你的第一个测试。

这个就简单了：

Done！

如果你还没有持续集成环境的话，那么请搭建它。

考虑到这是一个体力活，而且这方面的资料已经足够的多，我就不浪费大家的时间了。

顺带一提，如果你的分支比较多，而且构建比较多，那么你可以考虑 pipeline as pipeline 的方式进行构建。

某次代码重构中，我发现代码的测试覆盖率很高，过程中出了一些错误，重构手法不正确是一个问题。但是在重构的过程中，发现有些测试都是没有意义的，所以这让我意思到在构建防护网的时候，有必要审视一遍测试，查找测试代码中的坏味道。

常见的测试坏味道有：

有兴趣进一步了解的话，可以阅读《测试代码的坏味道》。也可以 coca tbs 来查找测试中的坏味道：