系列目录

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

 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. JsonUtil(基于Jackson的实现)

    JsonUtil(基于Jackson的实现) 前言: 其实,我一直想写一个有关Util的系列. 其中有四个原因: Util包作为项目的重要组成,是几乎每个项目不可或缺的一部分.并且Util包的Util ...

  2. Jenkins使用总结,2.0 新时代:从 CI 到 CD

    Jenkins近阶段使用的总结篇,只写了个引子,却一直未动手写完,今天补上. 前几篇文章提到在内网jenkins直接构建部署升级线上环境,job都是暴露在外面,很容易被误操作,需要做简单的权限控制,以 ...

  3. 你懂什么叫js继承吗

    说到继承呢?肯定有很多做java的朋友都觉得是一个比较简单的东西了.毕竟面向对象的三大特征就是:封装.继承和多态嘛.但是真正对于一个javascript开发人员来说,很多时候其实你使用了继承,但其实你 ...

  4. ElasticStack学习(八):ElasticSearch索引模板与聚合分析初探

    一.Index Template与Dynamic Template的概念 1.Index Template:它是用来根据提前设定的Mappings和Settings,并按照一定的规则,自动匹配到新创建 ...

  5. ServiceFabric极简文档-2 部署环境搭建-配置文件

    类型:ClusterConfig.Unsecure.MultiMachine 说明:至少3台机子 { "name": "SampleCluster", &quo ...

  6. 如何使用百度EasyDL进行情感分析

    使用百度EasyDL定制化训练和服务平台有一段时间了,越来越能体会到EasyDL的易用性.在此之前我也接触过不少的深度学习平台,如类脑平台.Google的GCP深度学习平台.AWS深度学习平台,但我觉 ...

  7. 跨站脚本攻击(反射型xss)笔记(一)

    环境:一个微信端(所以用浏览器演示UI有点变形) 下图是未插任何脚本时的原页面. 按惯例,上一波["><script>alert(1)</script>] 无弹 ...

  8. UVA101 The Blocks Problem 题解

    题目链接:https://www.luogu.org/problemnew/show/UVA101 这题码量稍有点大... 分析: 这道题模拟即可.因为考虑到所有的操作vector可最快捷的实现,所以 ...

  9. python黑帽子学习笔记1:pyqt5 designer+wmi实现进程监视器

    环境说明:python3.6 所需要模块:wmi.pyqt5.pythonMagick 先放上一张成品效果图,如图所示: 界面利用pyqt5的designer实现,画好界面如下图所示: 画好后,保存好 ...

  10. Supalle-Admin-Layout,一个PC端和手机端都合适用的后台页面模板

    Supalle-Admin-Layout主要使用有Vue.Element-UI.layui-icon,Ajax实现采用Fetch(是有这个打算,不过目前是jQuery.). 源码地址:https:// ...