测试驱动开发。如何处理重构未经测试的遗留代码？
我开始在我的 iOS 开发项目中采用测试驱动设计 (TDD) 行为和工作流程。但在遗留软件的环境中至少存在一个障碍。我经常需要向我不熟悉的现有代码库添加功能。我通常希望在开始使用代码库时进行重构，而代码库通常没有可用的测试来确保我的重构不会改变代码功能，或更糟糕的是，不会添加错误。
我的问题是，当代码不是从头开始编写而是他们要处理的遗留代码时，TDD 人们如何引导整个过程？
谢谢，
Doug
UPDATE
对于一个具体的例子，我使用 Martin Fowler 的 Refactoring 中的示例，用 Objective-C 重新编码作为 TDD（和 AppCode）的训练设备 >>
我根据测试构建了代码。我发现我需要向 Customer 类添加实例变量，以确保在编写代码时不会搞砸 statement 方法中的成本计算。这是我需要深入了解的根本问题。
I am beginning to adopt Test Driven Design (TDD) behaviors and workflow for my iOS development projects. There is at least one impediment though in the context of legacy software. I will often have to add features to a pre-existing code base that I am new to. I will typically want to refactor at the beginning of working with the code base which will often have no tests available to ensure that my refactor-ings are not altering code functionality or worse, adding bugs.
My question is how do TDD folks bootstrap the whole process when the code is not written from scratch but rather legacy code that they are brought in to work on?
Thanks,
Doug
UPDATE
For a concrete example, I am using the example from Martin Fowler's Refactoring re-coded in Objective-C as a training device for TDD (and AppCode) >>
I built the code from tests. I found I needed to add instance variables to the Customer class to ensure I didn't screw up the cost calculations in the statement method as I grew the code. This is the fundamental issue I need insight into.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，如果您不理解正在使用的遗留代码，则需要在执行您担心可能会改变行为的操作之前修复它。
在您的情况下，在了解遗留代码之后，我将编写针对该遗留代码运行的测试。一旦您对这些测试按预期运行感到满意，您就可以更好地测试重构的代码，以确保它像旧代码一样运行。
To begin with, if you don't understand the legacy code you're working with, you need to fix that before you do things which you're concerned may change behavior.
In your situation, after understanding the legacy code, I would write tests that will run against that legacy code. Once you're satisfied that these tests function as you expect, you're in a much better position to test your refactored code to ensure it functions as the old code did.