我继承了一个没有单元测试的遗留Web应用程序。我想补充一些，但我不知道从哪里开始。我应该将它们添加到旧代码中吗？或者只是新的代码？如果该代码与遗留代码交互怎么办？你会建议什么？
答案 0 :(得分：9)
首先，我建议对未来的所有变化进行单元测试，我想大多数人都会认为这对回归来说是一个好主意。
但是，对于现有代码，这是您需要了解您愿意或允许在产品中引入多少风险的情况之一。问题在于，当您开始对现有代码库进行单元测试时，您很快就会发现很多重构和设计优化的机会。
从我这里拿走它，如果你是一个善于设计的坚持者，但是你没有被授权进行激烈的重构决策，那么当你尝试编写测试时，你最终会心碎遗留部分 - 是的，如果它没有现有的测试套件，它将进行NEED重构。如果您不允许对生产应用程序进行高影响更改，那么您最终将实现我们称之为“垃圾适配器模式”的内容。祝你好运！
答案 1 :(得分：3)
我建议您获取Working Effectively with Legacy Code的副本。
我们在一个研究小组中完成了这本书。这很痛苦，但很有用。
主题包括：
您可以在http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf
看到此内容答案 2 :(得分：2)
是旧版应用分层？
如果是这样，首先将单元测试添加到后端/业务层
如果没有，将单元测试添加到新代码中，以及发现错误时（用于回归测试）
如果您有时间/野心对整个事物（最终）进行单元测试，请先启动功能列表（首先是关键功能），然后为这些功能添加单元测试，一次几个
答案 3 :(得分：2)
如果是你继承的代码，大概是你必须开始阅读它并理解它做什么和不做什么。我建议你编写单元测试，以反映你对代码库的不断增长的理解。最终，您将构建一个关于遗留应用程序的知识体系，其中“这些函数是通过这些测试的函数”而不是“这些函数是具有这些实现的函数”。然后，您将有更多的自由和信心，在不破坏事物的情况下进行更改。
答案 4 :(得分：2)
我不会为了进行测试而编写任何测试。我只会在发现错误或您要添加新功能时编写测试。然后编写测试以打包您需要更改/实现的代码，以定义它当前的功能。在出现错误的情况下，编写测试以证明错误已得到修复。在新代码的情况下，它应该做什么。现在去实现修复/新功能。如果您发现自己很想触摸测试“盒子”之外的代码 - 再写一些测试来填充该区域（或重新考虑您想要进行的更改）。根据需要逐步引入新测试，以最大化您在测试中的投资。编写测试来证明工作代码的工作原理似乎毫无意义，直到它被证明是坏的。
答案 5 :(得分：1)
如果网络应用程序未经过单元测试，则可能也不容易进行单元测试。将它置于单元测试之下可能会有风险，因为您没有[单位]测试，是的，鸡肉和鸡蛋。此外，这需要时间并且不会给应用带来太多价值。
我的目标是使用Selenium，Watir，HtmlUnit或HttpUnit，YMMV为应用程序的遗留部分编写端到端自动测试。这些测试（characterization tests）将确定您当前的应用程序行为，如单元测试，但从外部，允许您进行更改，以检测不需要的副作用。
为新代码编写单元测试，并在更改旧代码时，无论是修复问题还是添加新功能。
答案 6 :(得分：1)
在应用程序的已知“痛点”处编写测试。经常中断或通常具有较高风险的代码是一个很好的起点，因为它有助于在该领域建立防线的前线，并使团队暴露在该应用程序中的单元测试范围内。
每次针对应用程序打开缺陷时，请继续尝试编写单元测试以揭示此行为。它将在您修复时通知您，并希望将来再次引入它。
此外，查找需要重构的代码。任何重构工作都应该通过创建单元测试来开始。这有助于确保在您进行更改之前和之后都能正常工作。重构在开始时可能很难，因为存在“涟漪效应”的风险，其中一次破坏会以意想不到的方式对整个应用程序造成严重破坏。