unit-testing - 重写单元测试可以吗？

Question

我还在学习 OOP，每天我都会发现一些陌生的东西。因此，在编写单元测试时，函数名称似乎很常见，而且通常的程序设计已经定义。例如， “测试这个工厂或那个依赖容器，看看它是否按预期工作”。

作为一名学习者，我很确定我想随着时间的推移改变很多东西，从函数名称到代码结构再到函数本身的功能。显然，这意味着重写测试以使其通过。你遇到过这个问题吗？我读到的一些东西说一旦写完触摸测试是禁忌，那么你如何解决这个问题？

Answer 1

测试一旦写好就触碰是禁忌

当然，这完全是胡说八道。时间流逝，事情发生变化，代码不断发展，测试需要被触及。随意修改和重写测试，但要小心不要在此过程中意外丢失功能（当重写版本不测试以前版本所做的用例时）。

对我来说，这个问题根本不存在。

Answer 2

正如@Sergio 所说，如果被测类发生变化，你当然必须更改测试。

只是要注意一般更改测试：如果被测试的类是错误的，不要忘记确保新测试确实失败。当您首先编写新代码并编写测试时，您会在实现新功能和测试通过之前看到测试失败（TDD 的“红/绿”节奏）。当你改变测试时，你需要确保你所做的不仅仅是一个总是通过的测试。

对于您关于更改被测类的内容（名称、行为）的问题，您也可以以测试优先的方式轻松地做到这一点：

1. 更改测试以反映您希望对被测类进行的更改
2. 运行测试以验证它是否失败（或者如果名称更改，可能无法编译）[红色]
3. 更新类，看测试通过【绿】

Answer 3

要记住的重要一点是，测试代码与生产代码一样重要，如果不是，为什么还要费心呢？考虑到这一点，维护和重构测试与维护和重构生产代码一样重要。

也就是说，我不建议仅仅因为您的知识有所进步并且您不喜欢最初的方式而重写测试。如果一个测试正在测试一些有价值的东西，是可以理解的，并且总是通过，我会不管它。

Answer 4

我认为这取决于您的程序。如果您有一个非常庞大的程序，如果您不确定其他函数是否使用该函数，则不应重写您的测试。如果您正在开发中，如果您确定这不会造成麻烦，您可以更改它们。