如何做数据库unit testing？
我听说在开发使用数据库的应用程序时，你应该做数据库unit testing。 数据库unit testing的最佳实践是什么？ 在进行dbunit testing时，主要关心什么？如何做到“正确”？
数据库unit testing的最佳实践是什么？
DbUnit框架（允许将数据库置于已知状态并对其内容执行断言的testing框架）有一个列出数据库testing最佳实践的页面，根据我的经验，这是真实的。
进行dbunit testing时主要关心什么？
- 创build最新模式，pipe理模式更改
- 设置数据（参考数据，testing数据）和维护testing数据
- 保持独立的testing
- 允许开发人员同时工作
- 速度（涉及数据库的testing通常较慢，并且会使整个构build花费更多时间）
以及如何做到“正确”？
正如所暗示的，遵循已知的良好做法并使用专用的工具/框架：
- 如果可能，则优先select内存数据库（对于速度）
- 每个开发人员使用一个模式是必须的（以允许并发工作）
- 使用“数据库迁移”工具（àRoR）来pipe理模式更改并将模式更新为最终版本
- 构build或使用testing工具，允许在每次testing之前将数据库置于已知状态，并在执行后对数据执行断言（或在testing结束时回滚的事务内运行testing）。
看看这个链接 。 它介绍了在SQL Server中创buildunit testing存储过程以及不同types的unit testing以及何时使用它们的一些基础知识。 我不确定你使用的是什么DBMS，但显然这篇文章是面向SQL Server的。
从文章中被盗：
functiontesting
第一个也是最stream行的数据库unit testing类是functiontesting。 在我看来，functiontesting从数据库消费者的angular度testing数据库的核心function（或API）（如果您愿意的话）。 testing数据库的可编程性对象是这里的主线情景。 所以，在你的数据库中testing所有的存储过程，函数和触发器在我看来就是functiontesting。 要testing存储过程，您需要执行存储过程并validation是否返回了预期结果或发生了适当的行为。 但是，您可以testing的不仅仅是这些types的对象。 例如，您可以想象要确保某个视图从计算列中返回适当的计算。 正如你所看到的，这个领域的可能性很大。
模式testing
数据库最关键的方面之一就是它的模式，并且testing以确保数据库的行为像预期的那样是另一个重要的数据库unit testing类。 在这里，您经常需要确保视图以适当的顺序返回适当数据types的预期的一组列。 你可能想要确保你的数据库确实包含了你期望的1000个表。
安全testing
在当今时代，数据库中存储的数据的安全性至关重要。 因此，另一个重要的数据库unit testing类是testing数据库安全性的类。 在这里，您需要确保数据库中存在特定的用户，并且他们被分配了适当的权限。 您经常要创build负面testing，试图从受限制的表或视图中检索数据，并确保访问被适当地拒绝。
股票数据testing
许多数据库包含库存数据或种子数据。 这些数据很less变化，通常用作应用程序或最终用户的查找数据。 邮政编码及其相关的城市和州是这种数据的很好的例子。 因此，创buildtesting以确保您的库存数据确实存在于您的数据库中非常有用。
数据库unit testing时应该检查和考虑的项目列表
- 每个testing人员需要一个单独的数据库，以避免干扰其他testing人员/开发人员的活动
- 创build要testing的数据库的简单方法（这与在版本控制下拥有SQL Server数据库相关）。 当试图找出某些testing失败时发生了什么问题时，这是特别有用的
- 专注于特定领域并为单个模块创buildtesting，而不是一次覆盖全部。 细化地添加testing是高效的好方法
- 确保在testing失败时提供尽可能多的细节，以便于debugging
- 对所有testing使用同一个testing数据
如果使用tSQLt框架实现testing，则在处理来自多个SQL Server实例的大量数据库时，unit testing过程可能会变得复杂。 为了直接从SQL Server Management Studio维护，执行和pipe理unit testing，可以使用ApexSQLunit testing作为解决scheme
我很高兴你问到unit testing，而不是一般的testing。
数据库有许多function需要testing。 一些例子：
- 数据types/大小/字符集（尝试插入瑞典名称，或从现实世界的长URL或数字，看看你的列定义是否可以）
- 触发器
- Contraints（外键，唯一性…）
- 视图（检查数据是否正确包含/排除/转换）
- 存储过程
- 的UDF
- 权限
- …
这不仅在您更改数据库中的某些内容时非常有用，而且在您升级dbms或更改设置中的某些内容时也是如此。
一般来说，集成testing已经完成。 这意味着创build了像PHP或Java这样的编程语言的testing套件，并且testing会发出一些查询。 但是，如果某件事情失败了，或者有一些例外情况，就很难理解这个问题，原因有二：
- 问题可能出现在您的PHP代码中，或者PHPconfiguration中，或者在networking中，或者…
- 如果SQL语句embedded到另一种编程语言中，则SQL语句难以阅读和修改。
所以，在我看来，对于复杂的数据库，您需要使用用SQL编写的unit testing框架（使用存储过程和表）。 你必须仔细select它，因为那种工具没有被广泛使用（因此没有被广泛testing）。 例如，如果你使用MySQL，我知道这些工具：
- STK /单位http://stk.wikidot.com/stk-unit
- utMySQL http://utmysql.sourceforge.net/
我使用junit / nunit / etc和java或c＃编写数据库unit testing。 然后这些可以在集成服务器上运行，也许使用单独的模式到testing数据库。
最新的oracle sql开发者自带了一个内置的unit testing框架。 我看了看，但不会使用它。 它使用GUI来创build和运行testing，并将所有testing存储在数据库中，因此不容易将testing用例置于版本控制之下。 可能还有其他的testing框架，我想他们可能是特定于您的数据库。
良好的做法类似于常规的unit testing：
- 把testing放在源代码pipe理下
- 让testing跑得快 – 不要一次testing太多
- 使您的testing可重现
看看DBTestDriven框架。 它对我们很好。 从GitHub或他们的网站下载。
至于JVM开发，unit testing可以从JDBC摘要中受益：只要您知道哪些JDBC数据由DB访问引发，就可以“重播”这些JDBC数据。
因此，DB访问的情况下可以“复制”testing，没有目标DB：没有testing/数据隔离的复杂性，便于持续集成。
Acolyte是这样一个有用的框架（包括录制数据库结果的工作室GUI工具）： https ： //github.com/cchantep/acolyte
