系列目录

通过前面两节讲解,我们的测试类中已经有两个测试方法了,总体上如下

 public class mvc20
{
private readonly HttpClient _client; public mvc20()
{
var builder = new WebHostBuilder()
.UseContentRoot(@"E:\personal project\newTest2018\ConsoleApp1\CoreMvc")
.UseEnvironment("Development")
.UseStartup<CoreMvc.Startup>();
var server = new TestServer(builder);
_client = server.CreateClient();
}
[Fact]
public async Task SimpleGet()
{
var response = await _client.GetAsync("/HelloWorld/Hello");
response.EnsureSuccessStatusCode();
var responseStr = await response.Content.ReadAsStringAsync();
Assert.Equal("Hello,World", responseStr);
} [Theory]
[AutoData]
public async Task SimplePost(Student stud)
{
var content = new StringContent(JsonConvert.SerializeObject(stud), Encoding.UTF8, "application/json");
var response = await _client.PostAsync("/HelloWorld/StudentInfo", content);
response.EnsureSuccessStatusCode();
var result = await response.Content.ReadAsStringAsync();
Assert.True(!string.IsNullOrEmpty(result));
}
}

改进一:将对象初始化移到外部类中

以上方法看似没有问题,实际上却有一个性能陷阱,我们通过前面章节的知识已经知道,xunit里测试类的构造函数会在每一个测试方法运行的时候都执行一遍,通常情况下我们的测试代码远不止三几个,有时候几十个甚至上百个.这样每次都创建一个是非常影响性能的.并且这里的TestServer和_client都没有释放.此外就是web项目里可能每一个测试类都需要创建这样一个TestServer,这样重复的代码会复制很多次,带来维护困难.

我们前面讲到过,我们如果想要让一个对象在一个测试类中只初始化一次,就要让这个类实现IClassFixture泛型接口,类在初始化的时候会自动注入这个泛型对象的实体,并且只初始化一次,如果这个泛型对象实现了IDisposable接口,则会在测试类所有方法都执行完成的时候执行这个对象里的Dispose方法.

首先我们创建一个名为MyTestServerFixtrue的类,TestServer和HttpClient对象的初始化在这里执行.代码如下

public class MyTestServerFixtrue:IDisposable
{
public readonly HttpClient _client;
private readonly TestServer _server;
public MyTestServerFixtrue()
{
var builder = new WebHostBuilder()
.UseContentRoot(@"E:\personal project\newTest2018\ConsoleApp1\CoreMvc")
.UseEnvironment("Development")
.UseStartup<CoreMvc.Startup>();
_server = new TestServer(builder);
_client = _server.CreateClient();
} public void Dispose()
{
_client.Dispose();
_server.Dispose();
}

这里的方法和参数大部分都和前面在测试类中添加的一样,只是有以下几点需要注意:

1.把server变量放在构造函数外边,这样我们才能在Dispose里把它释放掉,不然无法定位到它.

2.把client变成public类型,因为我们需要在测试类中访问它.

下面我们再看测试类改造后的代码

 public class mvc20:IClassFixture<MyTestServerFixtrue>
{
private readonly HttpClient _client; public mvc20(MyTestServerFixtrue fixtrue)
{
this._client = fixtrue._client;
}
}

这里是主要代码,首先这个实现了IClassFixture,然后我们把无参构造函数改变成有参的,并且传入MyTestServerFixtrue类型对象,Xunit会自动注入这个对象,然后我们把这个对象里的httpclient赋值给本类的_client对象,这样我们就可以在本类中使用它了.

这样其它的测试类也可以实现IClassFixture<MyTestServerFixtrue>,如果想要改TestServer的配置只需要在MyTestServerFixtrue类中改就行了.

改进二:固定路由参数

我们看到前面讲到的两个测试方法提交的路径中都包含"/HelloWorld",它其实匹配控制器名,一般情况下同一个Controller下的方法的测试方法都写在同一个测试类中.这样Controller名称是固定的,我们可以把它单独抽离出来,只需要Action后面的路由.

我们把测试类改成如下:

 public class mvc20:IClassFixture<MyTestServerFixtrue>
{
private readonly HttpClient _client; public mvc20(MyTestServerFixtrue fixtrue)
{
var baseAddr = fixtrue._client.BaseAddress.AbsoluteUri;
string controllerName ="HelloWorld";
this._client = fixtrue._client;
if (!fixtrue._client.BaseAddress.AbsoluteUri.Contains(controllerName))
{
fixtrue._client.BaseAddress = new Uri(baseAddr + controllerName+"/");
}
}
[Fact]
public async Task SimpleGet()
{
var response = await _client.GetAsync($"{nameof(HelloWorldController.Hello)}");
response.EnsureSuccessStatusCode();
var responseStr = await response.Content.ReadAsStringAsync();
Assert.Equal("Hello,World", responseStr);
} [Theory]
[AutoData]
public async Task SimplePost(Student stud)
{
var content = new StringContent(JsonConvert.SerializeObject(stud), Encoding.UTF8, "application/json");
var response = await _client.PostAsync($"{nameof(HelloWorldController.StudentInfo)}", content);
response.EnsureSuccessStatusCode();
var result = await response.Content.ReadAsStringAsync();
Assert.True(!string.IsNullOrEmpty(result));
}
}

这里我们把controller的名称加到HttpClient的BaseUrl里面,然后发送get,post等请求的时候只要Action的名字,这里我们使用nameof关键字来获取action的名字,使用nameof关键字来获取的好处是:第一,我们点击方法名就可以快速定位到指定的方法.更为重要的是如果方法的名称改了,编译的时候就会出现编译错误,我们可以快速定位到错误然后修改.

改进三:资源路径改为相对路径

上面MyTestServerFixtrue类中的代码有一处有明显问题:那就是UseContentRoot里的路径是写死的,项目在本机上地址与在服务器上的或者与其它同事的绝大多数情况下是不一样的(因为大家项目所在的目录名不相同)这时候如果其它人调用这些代码就可能会出现错误.

我们可以使用相对路径来获取绝对路来解决这个问题,由于这两个项目的主文件夹在同一文件夹下面,因此测试项目向外退若干层就能够得到mvc项目的主目录了.

我们将MyTestServerFixtrue类的构造方法改为如下:

public MyTestServerFixtrue()
{
var rootPath = GetContentRootDir();
var builder = new WebHostBuilder()
.UseContentRoot(rootPath)
.UseEnvironment("Development")
.UseStartup<CoreMvc.Startup>();
_server = new TestServer(builder);
_client = _server.CreateClient();
}

这次我们不是再写死rootPath而是通过方法GetContentRootDir来获取.

下面我们来看这个GetContentRootDir方法

 private string GetContentRootDir()
{
var currentPath = AppDomain.CurrentDomain.BaseDirectory;
var relativePath = @"..\..\..\..\CoreMvc";
var combinedPath = Path.Combine(currentPath, relativePath);
var absPath = Path.GetFullPath(combinedPath);
return absPath;
}

首先我们先获取当前程序域的目录,也就是程序的运行目录,获取到它之后我们看看向上移动多少层能够到达包含mvc项目和这个test项目的文件夹,经查是四层,下面的相对路径我们就写为如变量relativePath定义的那样.

我们把它们组合在一起,然后通过Path.GetFullPath来获取到相对路径的绝路径.

改进四 设置超时

有时候服务器故障会导致请求非常慢,服务器很长时间无法返回请求,这就会导致集成测试代码一直'卡'着无法完成,这时候可以设置一个超时.设置非常简单,HttpClient有一个Timeout属性,设置相应的超时时间即可.HttpClient的默认请求超时时间是100s,这个值应该大部分时候不需要修改的,但是关于具体的业务,可能有一些方法本身执行时间特别长(业务逻辑非常复杂,sql语句非常复杂等)这时候可以单元给本次请求设置一个超时时间.比如说是150s,设置如下

     CancellationTokenSource cts = new CancellationTokenSource(TimeSpan.FromSeconds(150));
var response = await client.GetAsync("/Home/index", cts.Token);

这里定义一个CancellationTokenSource对象,并指定超时时间,然后把此对象的Token对象传给异步请求方法.

.netcore持续集成测试篇之测试方法改造的更多相关文章

  1. .netcore持续集成测试篇之开篇简介及Xunit基本使用

    系列目录 为了支持跨平台,微软为.net平台提供了.net core test sdk,这样第三方测试框架诸如Nunit,Xunit等只需要按照sdk提供的api规范进行开发便可以被dotnet cl ...

  2. .netcore持续集成测试篇之搭建内存服务器进行集成测试一

    系列目录 在web项目里,我们把每一层的代码的单元测试都通过并不代表程序能正常运行,因为这个过程缺失了http管道,很多时候我们还还需要把项目布在iis环境中或者在vs里启动iis express服务 ...

  3. .netcore持续集成测试篇之Xunit结合netcore内存服务器发送post请求

    系列目录 Web项目中,很多与用户数据交互的请求都是Post请求,想必大家都用过HttpClient构造过post请求,这里并不对HttpClient做详细介绍,只介绍一些常用的功能.并结合AutoF ...

  4. .netcore持续集成测试篇之MVC测试

    前面我们讲的很多单元测试的的方法和技巧不论是在.net core和.net framework里面都是通用的,但是mvc项目里有一种比较特殊的类是Controller,首先Controller类的返回 ...

  5. .netcore持续集成测试篇之web项目验收测试

    系列目录 通过前面的单元测试,我们能够保证项目的基本模块功能逻辑是正常的,通过集成测试能够保证接口的请求是正常的.然而最终项目交付我们还需要对项目进行页面的行为进行测试,比如页面布局是否正常,按钮是否 ...

  6. .netcore持续集成测试篇之Xunit数据驱动测试一

    系列目录 Nunit里提供了丰富的数据测试功能,虽然Xunit里提供的比较少,但是也能满足很多场景下使用了,如果数据场景非常复杂,Nunit和Xunit都是无法胜任的,有不少测试者选择自己编写一个数据 ...

  7. .netcore持续集成测试篇之 .net core 2.1项目集成测试

    系列目录 从.net到.net core以后,微软非常努力,以每年一到两个大版本的频率在演进.net core,去年相继发布了.net core 2.1和2.2,其中2.1是长期支持版,不断的快速更新 ...

  8. .net持续集成测试篇之Nunit常见断言

    系列目录 Nunit测试基础之简单断言 在开始本篇之前需要补充一些内容,通过前面搭建Nunit测试环境我们知道要使一个方法成为单元测试方法首先要在此方法所在类加上TestFixture注解,并且在该方 ...

  9. .net持续集成测试篇之Nunit参数化测试

    系列目录 在进行单元测试的时候,很多时候,很多时候我们都是在单元测试方法内部提供特定的值,但是这样测试往往造成样本数不足从而导致覆盖的结果不够全面,很多时候我们更想提供来自外部的,满足条件的一组值来进 ...

随机推荐

  1. java高并发系列-第1天:必须知道的几个概念

    java高并发系列-第1天:必须知道的几个概念 同步(Synchronous)和异步(Asynchronous) 同步和异步通常来形容一次方法调用,同步方法调用一旦开始,调用者必须等到方法调用返回后, ...

  2. 主机地址变更后,dubbo请求时依旧会寻址旧IP的问题

    机房迁移,导致测试服务器IP变更,比原于IP为192.168.1.105变更为10.1.9.120. 服务源码未做任何变更,启动服务时依旧是旧地址请求,此问题由dubbo本地注册中心的缓存所致,清理掉 ...

  3. wincc C脚本如何调用第三方动态链接库dll

    就Wincc本身脚本功能而言并不强大,但是wincc 脚本提供了第三方接口,如通用的Kernel32.dll,User32.dll,Gdi32.dll,大家如果对这些API接口感兴趣,可网上查找关于w ...

  4. Bzoj 3654 图样图森波 题解

    3654: 图样图森破 Time Limit: 30 Sec  Memory Limit: 512 MBSubmit: 123  Solved: 66[Submit][Status][Discuss] ...

  5. cogs426血帆海盗(网络流打法)

    这道题基本上来就能看的出来是网络流但难点在于它的结果貌似与最大流,最小割都没啥关系,我猜不少萌新像我一样想暴力枚举边(要是考试我就真这么做了),但很明显,出题人没打算让你这么水过,100000的数据不 ...

  6. Linux下安装docker与kubernetes(k8s)

    环境 安装是使用Vmware虚拟机下进行,操作系统是CentOS7 64位.规划是使用三台虚拟机搭建k8s的集群,网络使用NAT模式.三台的ip分别为: k8s-master:192.168.91.1 ...

  7. Spring Cloud 之 Zuul基础.

    一.概述  API 网关是一个更为智能的应用服务器,它的定义类似于面向对象设计模式中的 Facade 模式,它的存在就像是整个微服务架构系统的门面一样,所有的外部客户端访问都需要经过它来进行调度和过滤 ...

  8. Polya定理与Burnside引理

    也许更好的阅读体验 \(Burnside引理\) 公式 \(\begin{aligned}L=\frac{1}{|G|}\sum_{i=1}^{|G|}D_{G_i}\end{aligned}\) 一 ...

  9. 总结暨JAVAWEB学习开篇(一)

    匆匆,距上一篇博客已经过去7月有余,遂作文一篇总结暨JAVAWEB学习开篇. 1. 啃英文新概念.在多方讨教英语大佬后改变学习方式,通过背诵英文书籍以及多听英文录音来学习,效果还不错(等真正有成效了跟 ...

  10. RabbitMQ 实践之在处理异步任务中的流程

    一.背景: 我司的系统,用户可以创建任务,启动任务,但任务的运行需要很长的时间,所以采用消息队列的方式,后台异步处理. 这里所用到的是 RabbitMQ . 二.MQ 处理任务的流程 ① ② ③ ④ ...