没有单元测试，您怎么称呼重构？
任何人？
是。 这是一个技巧问题，不是吗？
没有单元测试的重构不称为重构。 这称为更改代码 。 甚至可以称其为破坏代码 。
随手添加测试
当您需要更改未经测试的代码时，添加单元测试很有用。 您实际上可以添加两种类型：
- 一个明显的用例–您已经了解了代码，并且可以看到它可以处理的用例，它很好而且很简单
- 表征-您不知道代码的用途，但是可以通过它运行一些数据，捕获输出，然后在单元测试中编写一个断言，指出我将来运行此命令时的输出应为不管这是什么
不幸的是，通过重构复杂的旧代码，后者是您拥有的最佳工具。 尽管一旦确定了所有测试的黑盒，就可以对代码进行一点剖析，添加用例驱动的测试，并最终将其置于控制之下。
如果我未经测试就更改了该怎么办？
您可以执行一些重构，尤其是使用IDE中的可用工具时，似乎并不能证明首先编写测试是合理的。
几个小时后，您可能会想– 是的，但是我把它弄坏了吗？ 。 而且您的分支上的代码已更改。.它可以通过所有当前的单元测试，但是否与master分支版本相同？ 我们需要退一步。
这是git可以拯救您的地方（可以使用其他源代码控制，但是长大了：现在是2020年，请使用git ）。
- 保持分支机构安全良好
- 回到`master`
- 使用缺少的单元测试创建一个新的功能分支
- 得到那些建筑，然后合并
- 返回到您的重构分支，然后重新建立基础
即使您稍微更改了接口，该技术也将有所帮助，因为在重新设置基准之后，您只需要调整一些测试代码即可……至少是可以预见的。
如果您滑入master的测试通过了功能分支，那么恭喜您。 如果不是，那么您可能希望以不同的方式进行重构……尽管您可以调试它并修复向前。
如果您有新的疑问，则可以重复该过程并将更多的测试滑入master的头中，并对它们进行重构。
如果很晚怎么办？
这就是git证明是Linus Torvalds的时间机器的地方。 我描述的过程可以应用于git历史记录中的任何提交 。 在进行大部分重构之前，先检查提交，然后将单元测试添加到从那里获取的功能分支中。 让它变成绿色。 然后，将该单元测试cherry-pick到以后的功能分支中，以查看其在当前代码中的作用。
TL; DR
- 您需要测试以支持重构
- 随时添加
- 或追溯性地将它们添加到早期版本的代码中，使用git来倒带
- 然后将通过原始代码的测试与最新的重构一起使用
翻译自: https://www.javacodegeeks.com/2020/04/the-unit-test-time-machine.html