现在我们已经TestServer为我们的ASP.NET核心应用程序执行了集成测试,我试图找出应该和应该是什么&#39 ; t 在构建API时进行测试。
Pre-ASP.NET Core,我通常会为我的API提供2x测试项目:
MyApi.UnitTests
=>测试控制器,服务,实用程序等测试一件事,其他一切都被嘲笑。
MyApi.IntegrationTests
=>测试数据库,外部API等。点击真正的数据库/服务。
现在,显然我们还需要UnitTests
。但我的问题是,我们应该用 TestServer 集成测试测试什么呢?
我最初的想法是用TestServer测试每个API端点,如下所示:
[Fact]
public async Task DoingAGetRequestToPeople_ShouldReturnPeopleAsJson()
{
// Arrange.
var client = new TestServer(new WebHostBuilder()
.UseStartup<Startup>()).CreateClient();
// Act.
var response = await client.GetAsync("/api/people");
// Assert.
response.EnsureSuccessStatusCode();
var responseString = await response.Content.ReadAsStringAsync();
Assert.NotNull(responseString);
var model = JsonConvert.DeserializeObject<IEnumerable<People>>(responseString);
Assert.NotNull(model);
}
但是,由于它是一个完整的E2E集成测试,也会点击数据库,因此也会测试它。那个测试是太多吗?那么我们是否需要单独的测试只是测试数据库调用? (例如&#34;单位&#34;测试,实际上击中了数据库?)
希望这是有道理的。基本上我正在寻找以下问题的答案:
三江源!
答案 0 :(得分:1)
我不确定我理解为什么测试视角/方法应该随着Asp.Net Core而改变,与之前的情况相比。我一定错过了一些方面。
无论如何,对你的问题:
我们应该使用TestServer集成测试测试什么呢?
我们应该/不应该使用TestServer测试的范围是什么。
我对这两个人的看法是:
测试整个API堆栈,从HTTP(S)端点到专用数据库服务器(或至少DB),因此遍历所有层,尤其是交叉问题(验证,身份验证, ...)。专用于仅用于测试目的,而不是开发人员(当测试在开发机器上运行时),也不是生产者(当测试在CI环境或类似环境上运行时)。
也许测试数据库可能与生产数据库的版本不完全相同,就像使用MS SQL Express而不是完整的MS SQL标准版/企业版一样,但是你至少仍然在打一个真正的数据库(例如,不是-memory one)以便连接字符串,视图,特定查询必须正常工作。
我们通常应该为API项目准备多少个测试项目?
我想这取决于您在测试项目中的粒度。如果您使用的是多层解决方案,其中app server分布在多个项目中,则每个项目都可以有一个单元测试项目,另外还有一个集成测试。
坚持你的出发点,我会说你可以继续进行两个测试项目:一个用于单元测试,一个用于集成测试。
但话又说回来,您可能还需要进行一些负载测试的测试项目。也许更多。
他们的责任是什么?
它们与pre -Asp.Net Core场景基本相同。单元测试仍然具有相同的职责。集成测试具有上面突出显示的那些职责。
HTH
答案 1 :(得分:0)