集成测试的的WebAPI和交易 [英] Integration Tests for WebAPI and transactions

问题描述

我有一个面向客户的ASP.NET Web API 有直接的SQL服务器调用以及调用其他的ASP.NET Web API进行数据操作。我想做一个端到端的在客户端REST API的集成测试，以测试其他所谓的REST API的的路线以及各种数据的操作是成功的。

I have a client facing ASP.NET Web API which has both direct SQL server calls as well as calling other ASP.NET Web APIs to do data operations. I want to do an end to end integration test of the client REST API to test the routes of the other called REST APIs as well as various data operations are successful.

这是我想要做的测试是（1）不同的REST API的路线是正确的，（2）添加和更新客户通过REST API是成功的。简单测试客户加入可以确保路由是否正确，以及数据操作成功。

The tests that I want to do are (1) the routes for different REST APIs are correct and (2) adding and updating a customer through the REST API is successful. Simply testing a customer is added can make sure the routes are correct as well as the data operation is successful.

我想在完成测试之后回滚事务。例如，在测试过程中，一个新客户是通过REST API创建像的http：//本地主机/客户/ POST 并在试验结束时，用户将被删除。

I want to rollback the transaction after completing the tests. For example, during the test, a new customer is created through a REST API like http://localhost/Customer/POST and at the end of the tests, the user is deleted.

是事务性操作可能的REST API和集成测试，欢迎任何建议。我使用NUnit在Visual Studio 2013环境。

Is transactional operation possible for REST API and any suggestion for Integration tests are welcome. I'm using NUNIT in Visual Studio 2013 environment.

推荐答案

不幸的是，当前的期权都不太理想，这里是我有一个比较大的项目设置 - 这在并不遥远从官方测试指南这里 。这一切都依赖于你的编译/测试自动化/部署过程（即ALM-应用程序生命周期管理中，我们使用Visual Studio发布经理2013）

Unfortunately the current options are not ideal, here is what I have set-up on a relatively large project - which is not far away from the official testing guide over here . This all relies on automation of your build/test/deploy processes (i.e. ALM- application life-cycle management, we use Visual Studio Release Manager 2013)

1）。在CI服务器上我们运行在每一个通过直接实例化控制器类和调用GET / PUT /后执行一些基本的测试签了一堆单元测试一样，我们会与其他单元测试/删除方法。这些用嘲笑的后端（无数据库连接）层，所以我都可以相互独立的测试API，数据，业务层。

1). On the CI server we run a bunch of unit tests on every checkin that perform some basic tests by instantiating the controller class directly and calling the get/put/post/delete methods like we would with any other unit test. These use mocked backend (no database connectivity) layers, so I can test the API, Data, Business layers all independently of each other.

2）。在夜间自动部署的一体化环境中，我们单独项目的每一层上再次运行上面的检查，然后再部署所有资产整合服务器。一旦部署完毕，我们再运行使用ASP.net的Web API客户端库的一些构建构检查（寻找他们的NuGet和asp.net网站）来执行真正的端到端，从客户测试一路通过每一层的分贝，在单元测试结束后，一些宣称我们运行一个简单的删除查询回滚数据。遗憾的是没有在present的WebAPI交易的概念，你必须创建自己的。要构建构/验收测试独立的单元测试中，我们对单元测试，使我们排除给予测试自定义操作过滤器。因此，我们构造的测试是这样的：

2). On the nightly automated deployment to the "integration" environment we run the above checks again on each layer of the project individually, and then deploy all assets to the Integration server. Once deployed, we then run some build conformation checks that use the "ASP.net Web API Client Library" (look for them on nuget and asp.net web site) to perform real end to end tests from a "client" all the way through every layer to the db, at the end of the unit test after some asserts we run a simple delete query to roll back the data. Unfortunately there is not a concept of "Transactions" in webapi at present, you have to create your own. To separate unit test from build conformation / acceptance tests, we have a custom action filter on the unit tests that allow us to exclude given tests. So our conformation tests look like this:

[Test, ConformationTest]
Public void TestGetCustomer(){
   //build get request here
}

3）。构建然后通过正式测试阶段，移动（跨分支手动合并）部署到LIVE之前，因为我们使用发布管道（Visual Studio的发行经理2013​​），我们知道环境之间的版本是相同的，因此我们只能做活部署GET请求屈指可数，以确保API运行重新启用服务器上的负载均衡器前。

3). The build then moves through a formal test stage (manual merge across branches) before being deployed to LIVE, because we use a release pipeline ("Visual Studio Release manager 2013") we know the builds between environments are identical, hence we only do a handful of GET requests on live deployment to make sure the API is running before re-enabling the server on the load balancer.

我们这样做的原因是，网络API需要在某处被托管测试它端到端，单元测试捕获的大多数错误立即入住 - 以及相关的每一个签旋转了一个VM晚间什么路线是昂贵的，如果你有几个开发者整天定期签到了。这确实涉及很多方面，但正如我所说不是100％的理想。

The reason we do this is that Web API needs to be hosted somewhere to test it end to end, the unit test catch most errors immediately on check-in - and the nightly anything route related as spinning up a VM on every checkin is expensive if you have several devs checking in regularly all day. This does cover most aspects, but as I said not 100% ideal.

这篇关于集成测试的的WebAPI和交易的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！