测试数据库代码的技巧

最新推荐文章于 2024-03-01 20:33:38 发布

danpu0978

最新推荐文章于 2024-03-01 20:33:38 发布

阅读量241

点赞数

文章标签：数据库 python java linux 大数据

几乎所有人都知道源代码属于版本控制。许多人都知道我们需要测试我们的代码。不少自动执行此操作。

但是，关于数据库，一切似乎都在改变。数据库内部和周围的许多内容未经测试。哎呀，有些脚本甚至不存在于版本控制中。如果您不敢相信（因为您还没有看过），那么您就是该死的混蛋。

这种情况的至少一个原因显然是：很痛。数据库测试往往是缓慢的，相互依赖的并且难以维护。授予。但是您知道什么：如果很痛，您应该更频繁地进行操作。它会教您在测试时到底是什么引起疼痛的，最终您将找到减轻疼痛的方法。这是一些在测试数据库相关代码时发现有用的想法：

给每个开发人员自己的数据库。这迫使您找到一种快速，轻松和可靠地建立数据库的方法。如果您的应用程序位于单个用户/架构/命名空间中，那么每个开发人员在单个数据库中拥有自己的用户/架构/命名空间就足够了。为了这个工作...
…该应用程序应与用户/架构/命名空间无关。它使在一台服务器上创建多个实例变得更加容易。
让应用程序驻留在单个用户/架构/命名空间中。如果您有多个相互依赖的名称空间（例如，用于模块的名称空间），将很难使它们与名称无关。
对于CI，Demo，QA等具有单独的实例。实际上，理想情况下，创建一个新实例应该很简单。
远离其自己的存储库随附的任何工具。如果已经看过大约十二种这样的工具，尽管有些工具在一开始看起来很有希望，但它们都完全无法与事物开发方面的其他工具集成。此类工具的示例包括用于从UML或ER模型生成代码的工具以及ETL工具。

前面提到的有关数据库和基础结构设置的地方。让我们看一下代码：

在数据库特定的语言（例如T-SQL或PL / SQL）上偏爱适当的语言（例如Java，C，PHP…）。如果您想知道为什么，请在您喜欢的数据库语言和通用语言之间进行比较。为此，您可以获得更好的IDE，单元测试支持，代码分析，代码覆盖率等等。如果在比较中没有赢得您的主要语言，请重新考虑。
有一个很小的层，可以与数据库进行所有交互。确保没有SQL或其他与数据库相关的代码泄漏出去。将该层作为依赖项注入需要它的任何人。这将使您可以测试几乎所有内容，而不必担心数据库。实际上，只有针对该集成层的测试才需要数据库进行测试。
支持独立于数据库的SQL或抽象各种数据库差异的库。早在人们宣称他们需要更换数据库供应商的情况下，这种情况就从未发生过。现在可以了。见下文。

接下来的几点将涉及实际测试：

考虑一个用于测试的内存数据库。许多数据库可以在内存模式下运行。它们非常适合测试，因为您可以在测试后将它们丢弃，并且它们比将任何数据库写入磁盘都快得多。当然，只有当您使用可以作为内存数据库运行的数据库系统或代码独立于数据库时，这才可能实现。因此，上一点。
如果不能像在内存数据库中那样使用数据库，请考虑将其放在RAM磁盘上。通过这种方法，我们的测试获得了巨大的性能提升。固态磁盘可能是下一个最好的选择，尽管我不确定它会对连续数据库测试的沉重负担有何反应。
使测试失败消息如此明确，您不必查看数据库即可分析测试失败。
使用代码来设置您的测试数据。使其简洁明了。如果您在表中需要一行，而对其值没有特殊要求，那么无论表中包含多少个外键，您都应该能够用一条简单的代码行来创建它。也就是说，您应该为测试数据提供一些DSL 。使用纯代码执行此操作将启用IDE的所有重构功能以进行测试。对于负载和性能测试，其他方法（例如加载生产数据或大量生成的数据）可能是合适的。
确保自己检查后清理。我发现在大多数情况下可用的两种方法：

为每个测试重新创建架构。这很慢，但确实很安全。
每次测试后都要回滚。这仅在测试内没有提交时有效。意思是：如果测试尝试回滚，但由于测试内部存在提交而失败，则某些完全不同的测试将失败。在这种情况下，找到糟糕的测试可能是一件非常令人沮丧的任务。

我们介绍了应用程序中与数据库相关的代码的测试。但是，我们还需要处理另一种代码：用于部署应用程序（或升级应用程序）的脚本

祝大家测试愉快。

翻译自: https://www.javacodegeeks.com/2012/01/tips-for-testing-database-code.html

关注