SQL Server 2005 的测试优先开发工具？
几年来，我一直在使用名为 qmTest 的测试工具，它允许我对某些 Firebird 数据库进行测试驱动的数据库开发。 我为新功能（表、触发器、存储过程等）编写测试，直到失败，然后修改数据库直到测试通过。 如果有必要，我会在测试上做更多工作，直到再次失败，然后修改数据库直到测试通过。 一旦该功能的测试完成并 100% 通过，我会将其保存在数据库的一组其他测试中。 在进行另一个测试或部署之前，我将所有测试作为一个套件运行，以确保没有任何问题。 测试可以依赖于其他测试，并且结果被记录并显示在浏览器中。
我确信这里没有什么新鲜事。
我们的商店的目标是在 MSSQLServer 上实现标准化，我想使用相同的过程来开发我们的数据库。 有谁知道允许或鼓励这种开发的工具？ 我相信团队系统可以，但我们目前不拥有它，而且可能在一段时间内不会拥有它。
我并不反对脚本，但欢迎更多的图形环境。
有什么建议么？
For several years I have been using a testing tool called qmTest that allows me to do test-driven database development for some Firebird databases. I write a test for a new feature (table, trigger, stored procedure, etc.) until it fails, then modify the database until the test passes. If necessary, I do more work on the test until it fails again, then modify the database until the test passes. Once the test for the feature is complete and passes 100% of the time, I save it in a suite of other tests for the database. Before moving on to another test or a deployment, I run all the tests as a suite to make sure nothing is broken. Tests can have dependencies on other tests, and the results are recorded and displayed in a browser.
Nothing new here, I am sure.
Our shop is aiming toward standardizing on MSSQLServer and I want to use the same procedure for developing our databases. Does anyone know of tools that allow or encourage this kind of development? I believe the Team System does, but we do not own that at this point, and probably will not for some time.
I am not opposed to scripting, but would welcome a more graphical environment.
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Team System 可能是最著名的解决方案，但您也可以尝试 TSQLUnit (SourceForge) 。
我自己没有使用过，但是这篇文章很好地介绍了它。
Team System is probably the best-known solution, but you could also try TSQLUnit (SourceForge).
I haven't used it myself, but this article does a decent job of introducing it.
查看http://www.sqlservercentral.com/articles/Testing/66553/
和 http://www.sqlservercentral.com/articles/Database+Design/66845/
这是一篇关于在 T-SQL 中完成所有操作的相当粗略的文章。
您是否考虑过使用 NHibernate 并使用 TestDriven 或类似的工具来进行测试？
Checkout http://www.sqlservercentral.com/articles/Testing/66553/
and http://www.sqlservercentral.com/articles/Database+Design/66845/
This is a fairly crude article about doing everything within T-SQL.
Have you thought about using NHibernate and using TestDriven or similar just for the tests?
在我无法访问 db pro 的团队系统的项目中，我使用了 sql 脚本与 msbuild 和 msbuild 的 sdc 任务库（http://www.codeplex.com/sdctasks）。 msbuild 脚本调用 sdc 任务以特定顺序（例如创建数据库、创建表等...）并在特定连接字符串上运行我的 sql 脚本。 脚本始终检查对象是否存在，然后首先进行拆卸，然后再重新构建它。
我将 sql 和 msbuild 脚本放置在常规 Visual Studio 数据库项目中（它没有什么特别的作用，因此您可以选择使用简单的空项目），因此一切都是源代码控制的。
使用这样一组脚本，您可以为每次测试运行设置一个新的数据库。 然后，您可以使用插入脚本向其中填充数据并对其运行单元测试。
这些脚本对于在不同环境（DEV/TST/QUA/...）中从头开始设置数据库也很有用
On projects where I didn't have access to team system for db pro's, I have used sql scripts combined with msbuild and the sdc tasks library for msbuild (http://www.codeplex.com/sdctasks). The msbuild script calls on an sdc task to run my sql scripts in a particular order (e.g. create db, create tables etc...) and on a particular connection string. The scripts always check if an object exists and do teardown first and build it back up.
The sql and msbuild scripts I place in a regular visual studio database project (which does nothing special, so you could choose to use a simple empty project), so everything is source-controlled.
with such a set of scripts , you can setup a new database for each test run. You can then use insert scripts to populate it with data and run unit tests against it.
These scripts are also useful for setting up databases from scratch in different environments (DEV/TST/QUA/...)
我能够充分应用测试驱动开发风格使用 TSQLUnit 的 SQL Server 数据库。 我遵循与您描述的相同的流程，首先编写一个失败的单元测试存储过程，然后进行必要的更改以使测试通过。 随着时间的推移，我还建立了一套测试，在执行时验证在进行任何新更改时没有任何问题。
有一些困难点（包括为现有存储过程编写测试的极端困难），但它特别适用于模式更改。 但是，我建议您查看 TST T-SQL Test Too1，它与 TSQLUnit (我必须自己推出）具有对断言的内置支持。
I was able to adequately apply a test driven development style against SQL Server databases using TSQLUnit. I followed the same flow as you described with writing a unit test sproc first that fails and then making the changes necessary for the test to pass. Over time, I also built up a suite of tests when executed validated that nothing broke while making any new changes.
There was some tough spots (including extreme difficulties in writing tests for existing sprocs) but it worked especially for schema changes. However, I would recommend looking at T.S.T. the T-SQL Test Too1 which unlike TSQLUnit (I had to roll my own) has built-in support for assertions.