当前位置：文江博客话题详情

在 sql server 2008 中实现数据库测试驱动开发的最佳方法是什么

发布于 2024-12-13 08:49:02 字数 627 浏览 0 评论 0原文

我正在开发一个解决方案来实现数据库测试驱动的开发，以测试存储过程的更改。到目前为止，我的想法是执行存储过程并以原始格式存储预期的数据和模式结果集。进行 sp 更改，然后再次执行存储过程并断言架构和数据相等。

首先，我将数据存储在 SQL Server 数据库中，例如：-

testdata.storedproc

ID - int
ResultsSet - int
Data - XML
Date - DateTime

testschema.storedproc

ID - int。
结果集 - 整数。
架构 - XML。
日期 - 日期时间。

一切都很顺利，直到我发现一个存储过程让我头疼：-

存储过程：-

有多个结果集。
具有包含相同列名的列，即。（人物.姓名，区域.名称）。
数据包含非法 xml 字符。
结果超过 120000 行。

这打破了我的初心，有没有人有任何关于数据库测试驱动开发的知识想要分享，或者有可以使用的替代解决方案？

原文

分享到QQ

分享到微博

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

发布评论

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

初懵 2024-12-20 08:49:03

我使用 DbFit 库（与 Fit/Fitnesse 结合）以测试优先的方式开发存储过程，取得了巨大的成功。测试以 HTML 形式编写，可以作为独立文件 (Fit) 或 Wiki 页面 (FitNesse)。 DbFit 管理数据库连接、执行查询和存储过程，并（默认情况下）将每个单独的测试包装在事务中以帮助保持事物的可重复性。

有关 Fit/Fitnesse 的更多信息，请参阅 FitNesse 网站以及标记为 fitnesse。 DbFit 可以在 GitHub 上找到。

回复收藏 0 原文

人间不值得 2024-12-20 08:49:03

测试数据存储解决方案

您将使用一种简单的原始存储格式，正如您所发现的，当您的存储过程可以在整个关系数据库中自由使用时，这种格式并不是很有帮助。

相反，您应该将每个测试的结果集保留在数据库中。然后将该数据库中的数据与您设置的另一个结果数据库或能够表示多个表中的多行和多列数据的简单数据格式进行比较。

您可以将预期的测试结果数据编写为 DML（可能从实际数据库中提取），这是一种可以处理更复杂的数据模式的自定义 Xml 格式，或者只是在自定义结果集数据库上执行数据库备份/恢复。

就我个人而言，我会尝试使用自定义的仅测试实体框架或 NHibernate 模型来导入架构（但没有存储过程，或任何可能使我的测试变得更加困难的东西），并使用 CreateDatabase 功能来部署测试模式。然后，您可以利用 .Net 代码来存储参考数据（对象初始值设定项）、正在使用的 ORM（提取和比较数据）和 NUnit。这与我在下面进行的头脑风暴非常吻合。

我对您的更高级别问题进行了一些头脑风暴

理想情况下，测试用例将单独测试逻辑。由于您无法真正拆分单个存储过程，因此您至少可以单独运行它。

以下是实现存储过程测试所需的一般描述。请注意，我所说的这些都是数据库方面的，但是您可以用任何使您的工具和测试用例更易于编写、理解和维护的内容来替换其中一些。

部件

输入数据

存储过程引用的最小精简模式
- 其中一部分是用于编译存储过程的最小 DDL
- 另一部分是为该测试用例提供存储过程的最小 DML
剥离当前存储过程引用的任何存储过程的模拟版本
要提供给存储过程的数据sproc 的参数
sproc 测试

输出数据

的脚本sproc 涉及的每个表的预期最终数据集
- 这只是针对早期架构运行的第二组 DML
从 sproc 返回的预期数据集

工具

用于运行测试用例的空模式用于
推送预期结果的空模式用于比较用于
比较表之间数据的工具或脚本（您的测试断言）

其中一些可以在同一存储过程的测试用例之间共享。您可以共享架构 DDL，也许是一些 DML，以及为每个测试设置/执行/比较/清理的逻辑。

执行

安排

创建被测模式（一开始为空）
运行 DDL 脚本
运行初始 DML 脚本
创建模拟存储过程
创建被测试存储过程

执行

执行被测试的存储过程，并将结果集存储在某处（另一个表？一组表？）

断言

为结果创建第二个空架构
运行 DDL 脚本
运行预期的 DML 脚本
可能将存储过程的返回结果复制到这个新模式中的新表中？
在两个模式之间运行比较脚本，并输出比较是否成功（数据相同）或失败（数据有任何差异）。
出于诊断目的，数据应该相同，或者应该输出一个不错的错误，告诉您差异是什么。

Solutions for test data storage

You are going with a simple raw storage format, which as you've discovered isn't very helpful when your sprocs are free to play around in an entire relational database.

Instead you should leave your result set from each test in a database. Then compare the data in that DB to another result DB you've set up, or a simple data format that is capable of representing multiple rows and columns of data in multiple tables.

You could author your expected test result data as DML (possibly extracted from an actual DB), a custom Xml format that can handle more complex data schemas, or simply do a DB backup/restore on a custom result set DB.

Personally, I'd try to cheat by using a custom test-only Entity Framework or NHibernate model to import the schema (but none of the sprocs, or anything that might make my testing harder), and use the CreateDatabase feature to deploy the schema for tests. Then you can take advantage of .Net code to store your reference data (object initializers), the ORM you're using (to extract and compare the data), and NUnit. This meshes well with the brainstorming I've had below.

Some brainstorming I've had on your higher level problem

Test cases ideally will test logic in isolation. Since you can't really split up a single stored procedure, you can at least run it in isolation.

Here's a general perscription for the things you would need to implement a stored procedure test. Note that I speak of these all in terms of the DB, but you could replace some of it with whatever makes your tools and test cases easier to write, understand, and maintain.

Parts

Input data

A minimal stripped-down schema that the sproc references
- One part is the minimal DDL that will get the sproc to compile
- The other part is the minimal DML that feeds the sproc for this test case
Stripped down mock versions of any sproc that the current sproc references
The data to feed into the sproc's parameters
The script for the sproc to test

Output data

The expected final data set for every table the sproc touches
- This is just a second set of DML run against the earlier schema
The expected data set returned from the sproc

Tooling

An empty schema to run the test case against
An empty schema to push the expected results to for comparison
Tooling or scripts to compare data between tables (your test assertions)

Some of this can be shared between test cases for the same sproc. You could share the schema DDL, maybe some of the DML, and the logic to set up/execute/compare/clean up for each test.

Execution

Arrange

Create the schema under test (it will start out empty)
Run the DDL scripts
Run the initial DML scripts
Create the mock sprocs
Create the sproc under test

Act

Execute the sproc under test, and store the result set somewhere (another table? set of tables?)

Assert

Create a second empty schema for your results
Run the DDL scripts
Run the expected DML scripts
Possibly copy over the sproc's return results to a new table in this new schema?
Run your comparison scripts between the two schemas, and output whether the comparison succeeded (the data was identical) or failed (there was any difference in the data).
For diagnostic purposes, the data should be identical, or a nice error should be output, telling you what the differences are.

回复收藏 0 原文

~没有更多了~