单元测试旧版ASP.NET WebForms应用程序[已关闭]

首先,我建议以后对所有的变更进行单元测试,我认为大多数人都会同意这是一个回归的好主意。

但是,对于现有的代码,这是需要查看您愿意或允许在产品中引入多少风险的情况之一。问题是,当您开始对现有代码库进行单元测试时,您很快就会认识到重构和设计优化的许多机会。

拿我来说吧,如果你坚持好的设计,但是你没有被授权去做剧烈的重构描述,那么当你试图为遗留部分编写测试时,你只会心碎——是的,如果它没有现有的测试套件,那么它需要重构。如果不允许您对生产应用程序进行高影响的更改,您将最终实现一些我们称之为“垃圾适配器模式”的东西。祝你好运!

我建议你拿一份 Working Effectively with Legacy Code .

我们在一个研究小组里看了这本书。这很痛苦,但很有用。

主题包括:

• 了解软件更改的机制:添加功能、修复错误、改进设计、优化性能
• 将遗留代码放入测试工具中
• 编写测试以防止引入新问题
• 可以与任何语言或平台一起使用的技术,包括爪哇、C++、C和C中的示例
• 准确识别需要更改代码的位置
• 处理不面向对象的遗留系统
• 处理似乎没有任何结构的应用程序

你可以看到一个短到这个在 http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf

传统应用程序是分层的吗?

如果是这样,首先将单元测试添加到后端/业务层

如果您有时间/抱负对整个事物进行单元测试(最终),那么开始一个特性列表(首先是关键特性)并为这些特性添加单元测试,一次添加几个。

如果这是您继承的代码,那么您可能必须开始阅读它,并理解它的作用和不作用。我建议您编写反映您对代码库日益理解的单元测试。最终,您将建立一个关于遗留应用程序的知识体系,它说“这些函数是通过这些测试的函数”,而不是“这些函数是具有这些实现的函数”。那么你将有更多的自由和信心在不破坏事物的情况下做出改变。

我不会为了测试而写任何测试。我只会在发现错误或您添加新功能时编写测试。然后编写测试来装箱您需要更改/实现的代码,以定义它当前的功能。在出现错误的情况下,编写测试以证明该错误已被修复。在新代码的情况下,它应该做什么。现在执行修复/新功能。如果您发现您想要在测试“框”之外接触代码,那么就在该区域中编写更多的测试(或者重新考虑您想要做的更改)。根据需要逐步引入新的测试,以最大化您在测试中所做的投资。编写测试来证明工作代码的工作似乎毫无意义,直到它被证明是中断的。

如果Web应用程序没有经过单元测试,那么它也可能不容易进行单元测试。把它放在单元测试下是有风险的,因为你没有[单元]测试,是的,鸡和鸡蛋。此外,这需要时间,不会给应用程序带来太多价值。

我的目标是写端到端的自动测试 Selenium , Watir ,HTMLUnit或HTTPUnit,YMMV,用于应用程序的遗留部分。这些测试( characterization tests )会像单元测试一样,限制当前应用程序的行为,但从外部进行更改,使您能够检测到不想要的副作用。

为新代码编写单元测试,在更改旧代码时,无论是用于修复问题还是添加新功能。

在应用程序的已知“痛点”编写测试。经常中断或通常具有较高风险的代码是一个很好的起点,因为它有助于在此领域建立一个前线防御,并使团队暴露在该应用程序中的单元测试范围内。

每次针对应用程序打开缺陷时,继续,尝试编写单元测试来公开此行为。它会让你知道什么时候它是固定的,并希望防止它在未来被再次引入。

此外,还要查找需要重构的代码。任何重构工作都应该在创建单元测试之前进行。这有助于确保它在您进行更改之前和之后都有效。由于存在“涟漪效应”的风险,重构在开始时可能很困难,其中一个破坏可能以意想不到的方式破坏整个应用程序。