.netcore持续集成测试篇之测试方法改造

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

.netcore持续集成测试篇之测试方法改造

系列目录通过前面两节讲解,我们的测试类中已经有两个测试方法了,总体上如下 public class mvc20 { private readonly HttpClient _client; public mvc20() { var builder = new WebHostBuilder() .UseContentRoot(@"E:\personal project\newTest2018\ConsoleApp1\CoreMvc") .UseEnvironment("Dev…

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

系列目录为了支持跨平台,微软为.net平台提供了.net core test sdk,这样第三方测试框架诸如Nunit,Xunit等只需要按照sdk提供的api规范进行开发便可以被dotnet cli工具调用,这样就解决了在持续集成过程中第三方框架依赖于windows平台上的各自runner的问题,使得测试框架开发者不需要花费很大功夫就可以快速迁移到.net core平台,同时封装了各测试框架的实现细节,对外暴露统一调用接口,大大减少devops开发者的工作量. 作为单元测试基础知识介绍,这里…

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

系列目录在web项目里,我们把每一层的代码的单元测试都通过并不代表程序能正常运行,因为这个过程缺失了http管道,很多时候我们还还需要把项目布在iis环境中或者在vs里启动iis express服务器进行集成测试.对于返回view的的方法我们通常是在浏览器中输入地址进行测试,对于返回数据的方法则使用诸如postman,fiddler,httpMaster pro,http debugger等工具进行测试.在这些工具中,postman相对好用,不但提供了测试数据的分组功能,还可以编写脚本来完成一…

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

系列目录 Web项目中,很多与用户数据交互的请求都是Post请求,想必大家都用过HttpClient构造过post请求,这里并不对HttpClient做详细介绍,只介绍一些常用的功能.并结合AutoFixture演示如何自动构造请求数据,简单手动创建Json或者Formdata的工作量,提高生产效率. 我们为上节创建的HelloWorld控制器添加一个StudentInfo方法,内容如下 [HttpPost] public IActionResult StudentInfo(Student st…

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

前面我们讲的很多单元测试的的方法和技巧不论是在.net core和.net framework里面都是通用的,但是mvc项目里有一种比较特殊的类是Controller,首先Controller类的返回结果跟普通的类并不一样,普通的类返回的都是确定的类型,而mvc项目的返回的ActionResult或者core mvc里返回的IActionResult则是一个高度封装的对象,想对它进行很细致的测试并不是一件很容易的事.因此在编写代码的时候建议尽量把业务逻辑的代码单元写到一个类中,Controlle…

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

系列目录通过前面的单元测试,我们能够保证项目的基本模块功能逻辑是正常的,通过集成测试能够保证接口的请求是正常的.然而最终项目交付我们还需要对项目进行页面的行为进行测试,比如页面布局是否正常,按钮是否能点击,点击后执行的动作是否正确,链接是否正常等功能进行测试,表单提交是否返回正确结果等.这些都是一些墨盒测试,一般是由专门测试人员来完成,然而随着web的发展,各种自动化工具越来越完善,有一些页面功能的测试也可以由程序员来编写自动测试代码完成.这里主要结合Selenium来介绍如何完成页面行为的测…

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

系列目录 Nunit里提供了丰富的数据测试功能,虽然Xunit里提供的比较少,但是也能满足很多场景下使用了,如果数据场景非常复杂,Nunit和Xunit都是无法胜任的,有不少测试者选择自己编写一个数据提供程序,但是更建议使用AutoFixture框架,一是因为自己工作中写的往往只是为了解决某个或者部分问题,只能随着业务逻辑的扩展才能不断的健壮起来,二是这样的框架往往缺少良好文档,主要由核心开发者口口相传,这就导致后来者遇到不明白了功能就去问核心开发者,影响这些开发者的其它工作. 下面介绍一下Xu…