我继承了一个没有单元测试的遗留Web应用程序。我想添加一些单元测试，但不知道从哪里开始。我应该在旧代码中添加它们吗？还是只在以后的新代码中添加？如果该代码与遗留代码交互怎么办？你有什么建议？
ASP.NET Webforms遗留应用程序的单元测试
13
- Gortok
6
复制。https://dev59.com/WHVC5IYBdhLWcg3w1E_w - S.Lott
3就此而言，这不是完全的重复，因为他的应用程序是非Web应用程序，而我的应用程序是ASP.NET。 - George Stocker
此外，他已经假设他将为他的遗留代码编写单元测试。而我更多的是“我想这样做，但是……”我希望社区不仅能说，“去进行单元测试”，还能说，“在X、Y和Z条件下不要进行单元测试”。 - George Stocker
更新标题，以便获得更好的回应，希望没问题。 - Gishu
我知道这个问题既古老又广泛，但我想知道你采取了哪个方向？你写了博客文章或类似的东西吗？ - TZHX
1@TZHX 最终你需要在你和框架之间放置接口，并将所有代码放在边界的你这一侧。因此不会直接绑定到数据源。 - George Stocker
7个回答
9
首先，我建议对所有更改进行单元测试，我认为大多数人都同意这是回归测试的好方法。
然而，对于现有的代码，这是一种需要考虑您愿意或允许引入多少风险到产品中的情况。问题在于，当您开始对现有代码库进行单元测试时，您很快会意识到许多重构和设计优化的机会。
听取我的建议，如果您注重良好的设计，但没有获得强制性的重构决策权，那么当您尝试为遗留部分编写测试时，您只会感到心碎 - 是的，如果它没有现有的测试套件，就需要重构。如果您不被允许对生产应用程序进行高影响力的更改，您最终将实现我们喜欢称之为“垃圾适配器模式”的东西。祝你好运！
然而，对于现有的代码，这是一种需要考虑您愿意或允许引入多少风险到产品中的情况。问题在于，当您开始对现有代码库进行单元测试时，您很快会意识到许多重构和设计优化的机会。
听取我的建议，如果您注重良好的设计，但没有获得强制性的重构决策权，那么当您尝试为遗留部分编写测试时，您只会感到心碎 - 是的，如果它没有现有的测试套件，就需要重构。如果您不被允许对生产应用程序进行高影响力的更改，您最终将实现我们喜欢称之为“垃圾适配器模式”的东西。祝你好运！
- jonathan.cone
3
我建议获取与遗留代码高效工作的副本。
我们在学习小组中阅读这本书，虽然很痛苦，但很有用。
主题包括：
- 理解软件更改的机制：添加功能、修复错误、改进设计、优化性能 - 将遗留代码放入测试框架中 - 编写测试以保护您免受引入新问题的影响 - 可以与任何语言或平台一起使用的技术，其中包括Java、C++、C和C# - 准确识别需要进行代码更改的位置 - 处理非面向对象的遗留系统 - 处理似乎没有任何结构的应用程序
您可以在http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf中看到简短的介绍。
我们在学习小组中阅读这本书，虽然很痛苦，但很有用。
主题包括：
- 理解软件更改的机制：添加功能、修复错误、改进设计、优化性能 - 将遗留代码放入测试框架中 - 编写测试以保护您免受引入新问题的影响 - 可以与任何语言或平台一起使用的技术，其中包括Java、C++、C和C# - 准确识别需要进行代码更改的位置 - 处理非面向对象的遗留系统 - 处理似乎没有任何结构的应用程序
您可以在http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf中看到简短的介绍。
- rtayek
2
这个传统应用程序是分层的吗？
如果是分层的，首先在后端/业务层添加单元测试
如果不是分层的，则在新代码上前进时添加单元测试，并在发现错误时进行回归测试
如果您有时间/雄心，想要逐步完成整个单元测试，请先列出功能列表（优先考虑关键功能），然后一次添加几个单元测试。
- Steven A. Lowe
1
不完全是这样。它有层次结构，但使用了几个不同的提供者。它的“层次结构”只是在旧的实体提供程序和数据访问层之上构建的新实体提供程序和数据访问层。 - George Stocker
2
如果你继承的是代码，那么你需要开始阅读并理解它的功能和不足之处。我建议你编写单元测试来反映你对代码库的逐渐理解。最终，你将建立起一个有关遗留应用程序的知识体系，其中包括“这些函数是通过这些测试的函数”而不是“这些函数是具有这些实现的函数”。然后你就可以更自由、更有信心地进行更改，而不会破坏原有的功能。
- Norman Ramsey
2
我不会仅仅为了有测试而写测试。只有在发现错误或添加新功能时，才会编写测试，并将其用于定义需要更改/实现的代码。在出现错误的情况下，编写测试以证明错误已被修复。在新代码的情况下，测试则是用来验证它应该做什么。现在去实现修复/新功能。如果你发现自己想要触及测试“盒”之外的代码，请编写更多测试以限制那个区域（或重新考虑您要进行的更改）。随着需要逐渐引入新的测试，以最大化测试所投资的价值。在工作正常的情况下编写测试似乎毫无意义，直到它被证明是有问题的。
- tvanfosson
1
在应用程序的已知“痛点”编写测试。经常出错或风险较高的代码是一个好的起点，因为它有助于在这个领域建立第一道防线，并让团队了解该应用程序中单元测试的范围。
每次针对应用程序开放缺陷时，尝试编写单元测试以暴露此行为。这将让您知道何时修复它，并希望防止将来再次引入它。
此外，寻找需要重构的代码。任何重构工作都应以创建单元测试为前提。这有助于确保在您进行更改之前和之后都可以正常工作。重构可能在开始时很困难，因为存在“连锁反应”的风险，其中一个故障可能会以意想不到的方式在整个应用程序中造成严重影响。
- Joseph.Ferris
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接