单元测试、Web 服务和数据库事务
我正在尝试为我的 Web 服务编写测试用例，以便我可以回滚它们可能所做的任何数据库更改。我可以尝试用事务范围包围它们，但如何指定事务的上下文？换句话说，事务如何知道要回滚到哪个数据库和服务器？就我而言，SQL 服务器以及 Web 服务都在本地运行。在您告诉我在没有客户端的情况下直接调用 Web 服务之前，请了解 Web 服务具有非常具体的运行时环境设置，对于我的测试用例来说，重现这些设置将是一件非常痛苦的事情。也许，交易范围不是我想要使用的，有其他选择吗？是否有可以调用的数据库函数来启动事务？谢谢。
I'm trying to write test cases for my web services in a way that I can rollback any database changes they may make. I can try to surround them with a transaction scope, but how do I specify a context for the transaction? In other words, how does the transaction know which database and server to rollback on? In my case, the SQL server runs locally as well as the web services. Before you tell me to call the web services directly without a client, please understand that the web services have very specific runtime environment settings that would be a royal pain to reproduce for my test cases. Perhaps, the transaction scope isn't what I want to use, is there an alternative? Is there a database function I could call to start a transaction? Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，您不进行单元测试。单元测试是关于测试单个小单元的代码（函数）。当您测试函数时，您正在为每个执行路径创建单元测试，以便完全覆盖已测试的代码。但是您的测试系统包括客户端到服务的通信以及服务到数据库的通信=几层代码+配置。这就是所谓的集成测试。
这里的问题是你是如何设计你的服务的？你们的服务有交易流程吗？事务流允许在客户端启动事务并将其传递给服务（分布式事务）。这不是默认行为，需要对 WCF 绑定进行特殊配置。如果您使用这种方法，您可以在测试中执行相同的操作。在测试时启动事务并在测试结束时回滚事务。如果您没有将服务设计为流动事务，您根本无法使用它，因为您在测试中启动的事务不会影响服务。在这种情况下，您有多种选择：
First you are not doing unit testing. Unit test is about testing single small unit of code (function). When you test a function you are creating unit test for each execution path so that you have full coverage of tested code. But your system under tests includes client to service communication and service to database communication = several tiers of code + configuration. That is called integration testing.
The problem here is how did you design your service? Does your service flow transactions? Transaction flow allows starting transaction at your client and pass it to the service (distributed transaction). It is not default behavior and it requires special configuration of WCF bindings. If you use this approach you can do the same in your test. Start transaction at test and rollback the transaction at the end of the test. If you didn't design service to flow transaction you simply can't use it because your transaction started in the test will not affect the service. In that case you have several choices: