【发布时间】:2009-07-30 20:40:25
【问题描述】:
让我们说我正在用一个我相信做同样事情的更简单的实现来替换一个过于复杂的方法。
将旧代码复制到包含单元测试的类中是否有意义,这样我就可以断言两者的结果相同?
谢谢
【问题讨论】:
标签: unit-testing testing refactoring tdd
让我们说我正在用一个我相信做同样事情的更简单的实现来替换一个过于复杂的方法。
将旧代码复制到包含单元测试的类中是否有意义,这样我就可以断言两者的结果相同?
谢谢
【问题讨论】:
标签: unit-testing testing refactoring tdd
是的。这是一个很好的开始方式。
但不要止步于此。
还要编写一个测试,其中包含旧代码用来生成的“最终答案”。
在某些时候,您会想要从单元测试中删除旧代码,因为它是错误的且无法维护。
【讨论】:
假设您正在使用源代码管理,我会这样做:
作为步骤 1 的一部分,您可能想为旧代码编写一点“线束”,以便在您的主要目标只是保留现有行为的情况下查看它吐出的值。重要的是您有通过旧实现的测试。
第 3 步的原因是,如果您发现遗漏了一个重要案例,您可以同步到针对旧代码提交测试的更改,添加新测试,验证它是否有效,然后重新同步到head 并验证它是否仍然有效(必要时修复新的实现)。
【讨论】:
绝对不是。您应该有测试来涵盖旧代码处理的每种情况、边界条件、错误等。如果您的测试很好,那么您的新代码在测试通过时是等效的。
能够自信地重构和消除旧代码是单元测试的主要好处之一。
【讨论】:
这很有意义
并确保旧代码在重写之前通过它们
然后用新代码替换旧代码,并确保它通过相同的测试
【讨论】:
你也可以让你的测试断言这两个方法返回相同的值。类似的东西
Assert.equals(oldMethod(someInput), newMethod(someInput));
然后你可以慢慢地从旧方法中“解放自己”。
【讨论】: