是否可以重写单元测试?

时间:2012-12-11 18:40:40

标签: unit-testing

我还在学习OOP,每天都会发现一些异国情调。因此,在编写单元测试时,看起来通常具有函数名称,并且通常已经定义了程序设计。例如,“测试 factory 依赖容器以查看它是否按预期工作”。

作为一个学习者,我很确定我会想要改变很多东西,从功能名称到代码结构,再到功能本身,随着时间的推移。显然,这意味着重写测试以使它们通过。你有没有遇到这个问题?我读过的一些事情就像是一旦写完就触摸测试是禁忌的,那你怎么解决这个问题呢?

4 个答案:

答案 0 :(得分:5)

  

一旦写完就触摸测试是禁忌

当然,这完全是胡说八道。时间过去,事情发生变化,代码发生变化,需要触及测试。随意修改和重写测试,但要注意不要在此过程中意外丢失功能(当重写版本不测试以前版本的情况时)。

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

答案 1 :(得分:2)

正如@Sergio所说,当然,如果被测试的班级发生变化,你必须改变测试。

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

关于改变被测试类(名称,行为)的问题,您也可以以测试优先的方式轻松完成此任务:

  1. 更改测试以反映您要对所测试的课程所做的更改
  2. 运行测试以验证它是否失败(或者如果名称更改,可能无法编译)[红色]
  3. 更新课程并查看测试通过[绿色]

答案 2 :(得分:2)

要记住的一件重要事情是测试代码和生产代码一样重要,如果不是,为什么还要烦恼呢?考虑到这一点,维护和重构测试与维护和重构生产代码同样重要。

那就是说,我不建议重写测试只是因为你的知识已经向前发展而你不喜欢你最初的方式。如果测试正在测试一些有价值的东西,可以理解,并且总是通过,那么我就不管它了。

答案 3 :(得分:1)

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