测试数据密集型遗留应用程序的技巧

发布于 2024-07-24 13:15:32 字数 351 浏览 8 评论 0原文

我正在开发一个非常大的数据密集型遗留应用程序。代码库和数据库规模庞大。大量业务逻辑分布在所有层中，包括存储过程中。

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

您采取了哪些方法（如果适用）？什么有效？什么没有& 为什么？任何建议，将不胜感激。谢谢。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

一曲爱恨情仇 2024-07-31 13:15:32

获取有效使用旧代码的副本作者：迈克尔·费瑟斯。它充满了使用大型、未经测试的代码库的有用建议。

另一本好书是面向对象的重新设计模式。本书的大部分内容并不专门针对面向对象软件。全文可免费下载 PDF 格式。

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

自动化构建和部署
将数据库模式纳入版本控制（如果尚未）。通常，数据库包含事务代码在运行之前需要存在的参考数据。也将其置于版本控制之下。 dbdeploy 等工具可以帮助您轻松重建架构并从一系列增量中引用数据。
将数据库版本（以及任何其他基础设施服务）安装到您的开发工作站上。这将使您能够处理数据库而无需不断地通过 DBA。它也比在远程数据中心的共享服务器上使用架构更快。所有主要的商业数据库服务器都有可在 Windows 上运行的免费（如啤酒）开发版本（如果您陷入在 Windows 上开发并在 Unix 上部署的尴尬境地）。
在开始处理某个代码区域之前，请编写大致涵盖您正在处理的区域的行为的端到端测试。端到端测试应该从外部测试系统——通过控制其用户界面或通过网络服务进行交互——这样您就不需要更改代码来将其安装到位。它将充当（不完美的）回归测试，让您更有信心将系统内部重构为更容易进行单元测试的结构。
如果有手动测试计划，请阅读它们并查看哪些内容可以自动化。大多数手动测试计划几乎完全是脚本化的，因此对于自动化来说是唾手可得的成果
一旦您获得了端到端的测试覆盖率，在修改和/或扩展代码时将代码重构为更松散耦合的单元。用单元测试包围这些单元。

要避免的事情：

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

Get a copy of Working Effectively with Legacy Code by Michael Feathers. It is full of useful advice for working with large, untested codebases.

Another good book is Object Oriented Reengineering Patterns. Most of the book is not specific to object-oriented software. The full text is available for free download in PDF format.

From my own experience: try to...

Automate the build and deployment
Get the database schema into version control, if it isn't yet. Usually databases include reference data that the transactional code needs to exist before it can work. Get this under version control too. Tools like dbdeploy can help you easily rebuild a schema and reference data from a sequence of deltas.
Install a version of the database (and any other infrastructure services) onto your development workstation. This will let you work on the database without continually having to go through DBAs. It's also faster than using a schema on a shared server in a remote datacentre. All major commercial database servers have free (as in beer) development versions that work on Windows (if you're stuck in the unenviable situation of developing on Windows and deploying on Unix).
Before starting work on an area of the code, write end-to-end tests that roughly cover the behaviour of the area you're working on. An end-to-end test should exercise the system from outside -- by controlling its user interface or interacting through network services -- so you won't need to change the code to put it into place. It will act as an (imperfect) regression test and give you more confidence to refactor the internals of the system towards a structure that is easier to unit test.
If there are manual test plans, read them and see what can be automated. Most manual test plans are almost entirely scripted and so are low-hanging fruit for automation
Once you've got end-to-end tests coverage, refactor the code into more loosely coupled units as you modify and/or extend it. Surround those units with unit tests.

Things to avoid:

Copying data from the production database into the environment you use for automated testing. This will make your tests unpredictable. Sure, run the system against a copy of production data, but use that for exploratory testing, not regression testing.
Rolling back transactions at the end of tests to isolate tests from one another. This will not test behaviour that only happens when transactions are committed, and will throw away data that is valuable for diagnosing test failures. Instead, tests should ensure the database is in a known initial state when they start.
Creating a "tiny" data set for tests to run against. This makes tests hard to understand because they cannot be read as a single unit. The "tiny" data set soon grows very large as you add tests for different scenarios. Instead, tests can insert data into the database to set up the test-fixture.

回复收藏 0 原文