Syn*_*nox 14 java validation refactoring
我正在使用遗留的Java代码,没有任何单元测试.为了使用该项目,需要重构许多类.
许多重构可以用eclipse完成,我是手工做的.经过一些重构后,我回顾了对cvs-HEAD的差异,但我真的不能确定一切都是100%正确的.
问题:如何验证重构,这与前一版本的数学相同？我希望有一个工具,但我也接受"基本的人类算法"作为解决方案.
我知道,"运行你的JUnit-Tests"是最好的答案,但遗憾的是,我的项目中没有任何答案.
谢谢!
Ita*_*man 34
在" TDD By Example "中有一个特定的部分讨论它.问题是您需要单元测试来重构,但复杂的代码通常是不可测试的.因此,您希望重构以使其可测试.周期.
因此,最佳策略如下:
做微小的重构步骤.当步骤很小时,人们更容易确保整体行为完好无损.仅选择可提高可测试性的重构.这是你的直接目标.不要考虑支持未来的功能(或任何类似的东西).试想一下"我怎样才能让单元测试能够测试这个方法/类".
一旦方法/类变得可测试,就为它编写单元测试.
重复此过程将逐渐使您进入测试的位置,从而可以更积极地进行重构.通常,这个过程比预期的要短.
如果你认为你可以通过引人注目的方案来检测到这一点,那么你将会走下一个滑坡.正如其他响应者之一已经说过的那样,两个程序是否相同的问题是不可判定的(通过图灵机).
如果您没有单元测试,我建议您至少设置一个回归测试工具.获取一些输入的快照和程序的一些输出版本1生成/生成,通过版本2运行它并确保结果相同.
如果它是一个GUI,我希望它有MVC分离,所以你可以单独测试模型,否则你可能会卡住.
问题:如何验证重构,这与前一版本的数学相同？我希望有一个工具,但我也接受"基本的人类算法"作为解决方案.
严格来说,重构是一组众所周知的转换,已被证明可以保留代码的语义.请参阅重构面向对象的框架.其他所有东西都应该被称为重新设计,但我同意两者都可以互换使用.
关于语义保存的推理很难,是一个开放的研究课题.例如,请参阅正式化行为保留程序转换.
直到我们有有效的工具来检查语义保存,最好还是要依靠测试.另一种让您对变更更有信心的方法是添加断言和合同.它将迫使你进行审查并思考可能发生了什么变化,什么是不变量,什么可以更深入地打破.
| 归档时间： |
|
| 查看次数： |
588 次 |
| 最近记录： |