测试数据密集型遗留应用程序的提示

Mic*_*ael 9 legacy unit-testing

我正在研究一个非常大的数据密集型遗留应用程序.代码库和数据库都是大规模的.大量的业务逻辑遍布所有层,包括存储过程.

是否有人建议如何开始将"单元"测试(技术上的集成测试,因为他们需要跨几层测试几乎任何给定过程的单个方面)以有效的方式应用到应用程序中?当前的架构不容易支持任何类型的注入或模拟.正在编写新代码以便于测试,但遗留代码呢?由于数据库本身和业务逻辑的强烈依赖性,我目前正在使用内联sql来查找用于测试的数据,但这些都非常耗时.创建视图和/或存储过程是不够的.

您采取了哪些方法(如果适用)?什么有用?什么没有&为什么?任何建议,将不胜感激.谢谢.

Nat*_*Nat 12

获取Michael Feathers的"有效使用遗留代码"的副本.对于使用大型未经测试的代码库,它充满了有用的建议.

另一本好书是面向对象的再造模式.本书的大部分内容并非针对面向对象的软件.全文可以PDF格式免费下载.

根据我自己的经验:尝试......

  • 自动化构建和部署
  • 将数据库模式转换为版本控制(如果尚未).通常,数据库包括事务代码在工作之前需要存在的引用数据.在版本控制下也可以获得它.像dbdeploy这样的工具可以帮助您轻松地重建模式并从一系列增量中引用数据.
  • 将数据库版本(以及任何其他基础结构服务)安装到开发工作站上.这将使您可以在不必经历DBA的情况下处理数据库.它也比在远程数据中心的共享服务器上使用模式更快.所有主要的商业数据库服务器都有免费(如啤酒)开发版本,可以在Windows上运行(如果你遇到了在Windows上开发和在Unix上部署的不利环境).
  • 在开始处理代码区域之前,编写端到端测试,大致覆盖您正在处理的区域的行为.端到端测试应该从外部运行系统 - 通过控制其用户界面或通过网络服务进行交互 - 因此您无需更改代码即可将其置于适当的位置.它将充当(不完美)回归测试,让您更有信心将系统内部重构为更易于单元测试的结构.
  • 如果有手动测试计划,请阅读它们并查看可自动化的内容.大多数手动测试计划几乎都是完全编写脚本的,因此对于自动化来说,这些计划很少
  • 一旦获得端到端测试覆盖率,在修改和/或扩展时将代码重构为更松散耦合的单元.用单元测试包围这些单元.

要避免的事情:

  • 将数据从生产数据库复制到用于自动测试的环境中.这将使您的测试无法预测.当然,针对生产数据的副本运行系统,但将其用于探索性测试,而不是回归测试.
  • 在测试结束时回滚事务以将测试彼此隔离.这不会测试仅在事务提交时发生的行为,并且会丢弃对诊断测试失败有价值的数据.相反,测试应确保数据库在启动时处于已知的初始状态.
  • 为要运行的测试创建"微小"数据集.这使得测试难以理解,因为它们不能作为单个单元读取.随着为不同场景添加测试,"微小"数据集很快就会变得非常大.相反,测试可以将数据插入数据库以设置测试夹具.