不定期更新的

在平时的开发中，我们很少会关注到测试的问题，更别说集成测试了，除非是公司有硬性要求或者是自己的开源项目中，为了整体架构的完整性，需要用测试来做辅助点缀，而更多的也仅仅是单元测试（说的就是我自己????），最近在写书的时候才进一步考虑到这一点，如何在一个ASP.NET Core框架中，引入集成测试呢？

这里我结合这三年开源的经验，总结了一些心得，给大家分享一下，如果有更好的建议，欢迎在评论区进行留言哟。

PS：单元测试就不说了，比较简单，最多就是依赖注入和MOCK的问题，不会的话也可以留言。

方案一：万物皆可Mock

在软件测试当中，我们经常，甚至是到处都会用到mock来处理对象实例化的问题，在单元测试中，mock十分常见，毕竟是为了测试一个小模块，其他的就不需要考虑，直接mock就行了，如果在集成测试的时候，如何测试接口呢，比如BlogController如何使用？我在blog.core项目中，就是这么使用到的，示例代码如下：

 Mock<IBlogArticleServices> mockBlogSev = new Mock<IBlogArticleServices>();
 Mock<ILogger<BlogController>> mockLogger = new Mock<ILogger<BlogController>>();
 BlogController blogController;
 private IBlogArticleServices blogArticleServices;
 DI_Test dI_Test = new DI_Test();
     var container = dI_Test.DICollections();
     blogArticleServices = container.Resolve<IBlogArticleServices>();
     blogController = new BlogController(mockLogger.Object);
 
  说句实话，这并非是集成测试，这种写法可能比较低端，通过mock配合new，创建了控制器，然后调用接口，看起来不是很高大上，而且集成测试本来就是要测试整体性，不能把所有的参数都mock吧。同时官方好像也说过，不要到处使用mock。
 
 
而且，这种方案，也要考虑如何使用依赖注入的问题！
 
 
所以这种方案做集成测试我给：
⭐⭐
 
 
方案二：实例化TestServer对象
 
 
  这种是比较常见的，也是微软官方架构项目eShopOnContainers的推荐方案，简单来说，就是微软提供了一个TestSever的类，为我们提供一个类似WebHost的宿主服务器，只不过是测试服务器，那如何测试Controller控制器呢，示例代码如下：
 
 
 public TestServer CreateServer()
     var path = Assembly.GetAssembly(typeof(CatalogScenariosBase))
       .Location;
     var hostBuilder = new WebHostBuilder()
         .UseContentRoot(Path.GetDirectoryName(path))
         .ConfigureAppConfiguration(cb =>
             cb.AddJsonFile("appsettings.json", optional: false)
             .AddEnvironmentVariables();
         .UseStartup<Startup>();
         .MigrateDbContext<CatalogContext>((context, services) =>
             var env = services.GetService<IWebHostEnvironment>();
             var settings = services.GetService<IOptions<CatalogSettings>>();
             var logger = services.GetService<ILogger<CatalogContextSeed>>();
             new CatalogContextSeed()
             .SeedAsync(context, env, settings, logger)
             .Wait();
         .MigrateDbContext<IntegrationEventLogContext>((_, __) => { });
     return testServer;
 
  可以看到，通过new TestServer()的方式，生成一个服务器，就可以发起请求了，核心的还是我们的WebHostBuilder。
 
 
至于如何调用就更简单了，直接对server发起HttpClient请求即可：
 
 
  using (var server = CreateServer())
      var response = await server.CreateClient()
          .GetAsync(Get.ItemById(1));
      response.EnsureSuccessStatusCode();
 

  这种是很简单的，而且也不用考虑mock的问题，毕竟用的直接就是web项目的WebHost宿主机Builder来构建的。
 
 
  但是有一个很致命的问题，我们在.NET5以后，使用Autofac做依赖注入的容器，而且ConfigureServices也是没有返回值的，这样在使用上面的TestServer，就会报错，提示找不到Autofac服务。
 
 
  但是如果你查看eShopOnContainers的源码后，就知道他们还是将ConfigureServices做了返回值处理：
 
 
 public IServiceProvider ConfigureServices(IServiceCollection servic
     // 自定义服务扩展
     services.AddAppInsight(Configuration)
         // and so on...
         .AddCustomMVC(Configuration);
     // 使用Autofac依赖注入容器
     var container = new ContainerBuilder();
     container.Populate(services);
     return new AutofacServiceProvider(container.Build());
 
  如果你能接受这种依赖注入的方式的话，也是可以使用这种方案的，这是一个注意点，要知道。
 
 
所以这种方案做集成测试我给：
⭐⭐⭐⭐
 
 
方案三：使用.UseTestServer()
 
 
  除了上面的这种方式，还有一种方式，也是官方提供的，比较类似，也是通过创建宿主机服务器的形式，不过是新的HostBuilder的ConfigureWebHostDefaults方式创建的，示例代码如下：
 
 
public static IHostBuilder GetTestHost()
    return new HostBuilder()
            //替换autofac作为DI容器
            .UseServiceProviderFactory(new AutofacServiceProviderFactory())
            .ConfigureWebHostDefaults(webBuilder =>
                webBuilder
                .UseTestServer()
                .UseStartup<Startup>();
            .ConfigureAppConfiguration((host, builder) =>
                builder.SetBasePath(Directory.GetCurrentDirectory());
                builder.AddJsonFile("appsettings.json", optional: true);
                builder.AddEnvironmentVariables();
 
  既然上面说了我们不能单独处理自定义容器，我们就和之前一样，指定就好，设计思路和我们的WebApi中的Program.cs特别像，然后使用起来就更加简单了：
 
 
 using var server = await ArticleScenariosBase.GetTestHost().StartAsync();
 // Action 发起接口请求
 var response = await server.GetTestClientWithToken()
     .GetAsync("/api/blogs?page=1&pageSize=5");
 // Assert 确保接口状态码是200
 response.EnsureSuccessStatusCode();
 
  这种方案不仅兼容了第二种方案的优点，而且对之前我们设计的Autofac依赖注入容器没有做任何的修改。
 
 
所以这种方案做集成测试我给：
⭐⭐⭐⭐⭐
 
 
编者按：Blog.Core开源三周年
 
 
 个人开源项目Blog.Core马上就已经开源三周年了，经过许许多多的小伙伴功能努力的结果，希望给ASP.NET Core在国内的推广，提供一个落地级别的案例。
 
 
 A、累计提交上千次Commit；
 
 
 B、配合前、后、认证、鉴权一体化方案；
 
 
 C、不完全统计，被60+公司使用中；
 
 
1.希望更多的小伙伴参与并提交PR。
 
 
2.希望更多的公司和组织使用，提供宝贵生产意见。
 
 
3.希望可以得到组织的孵化，让项目更进一步，有意者可以联系我。
 
 
Tips: 九月新内容，敬请期待。
 
 
HAPPY EVEY DAY!
 
                        原文链接：https://github.com/anjoy8/Blog.Core
                                    Intro
之前我的项目里的集成测试是随机一个端口，每次都真实的启动一个 WebServer，之前也有看到过微软文档上 TestServer 的介绍，当时没仔细看过以为差不多就没用，一直是启动了一个真正的 WebServer 去跑集成测试的，上次分享 Xunit.DependencyInjection 改造测试项目的时候，写的烂代码被大师看到了之后， 大师建议用 TestServer 来做集成测试，使用 TestServer 不会真正的占用端口号，不会出现权限问题，于是扒了扒 TestServer 的源码，并用 TestServer 改进了集成测试项目，感谢大师[献花鲜花]~~
Sample
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。
实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题，在全局上很可能暴露出来。
摘自百度百科
ASP.NET Core 集成测试
新建一个 ASP.NET Core Webapi 项目：
修改一下自带的Val...
如果您是执行TDD的ASP.NET Core开发人员，您可能会遇到一些问题。您的测试不涵盖您的Program类和Startup类。您的模拟框架有助于模拟内部依赖项，但不能模拟外部依赖项，例如其他公司制作的Web服务。此外，也许您决定不测试某些类，因为要模拟的内部依赖项太多。在本文中，我将解释如何解决这些问题。
如果您对.NET Core 3.1（我在这里使用的版本）的TDD有一些经验，这将很有帮助，最好使用xU
Asp.Net Core 1.0
1 准备工作
申请微信公众平台接口测试帐号，申请网址：（http://mp.weixin.qq.com/debug/cgi-bin/sandbox?t=sandbox/login）。申请接口测试号无需公众帐号，可以直接体验和测试公众平台所有高级接口。
1.1 配置接口信息
1.2 修改网页授权信息
点击“修改”后在弹出页面填入你的网站域名：
2 新建网站项目
2.1 选择ASP.NET Core Web Application 模板
2.2 选择Web 应用程序，并更改身份验证为个人用户账
&lt;project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://...
                                    文章目录前言单元测试xUnitFactTheory控制器小结附录
从开始敲代码到现在，不停地都是在喊着记得做测试，记得自测，测试人员打回来扣你money之类的，刚开始因为心疼钱（当然还是为了代码质量），就老老实实自己写完自己跑一遍，没有流程没有规划没有测试文档，就是自己整理一组数据跑一遍，最后依然还是让测试人员老老实实把一大堆测试问题扔给你。
首先，还是来聊聊为啥要搞测试吧。
https://edu.csdn.net/course/detail/36074
Python实战量化交易理财系统
https://edu.csdn.net/course/detail/35475
JSON Web Token 经过数字签名后，无法伪造，一个能够在各方之间安全的传输JSON对象的开放标准（RFC 7519）
参考前文 [翻译]Introduction to JSON Web Tokens - 、天上月 - 博客园 (cnblogs.com)
                                    一直打算写一篇关于 ASP.NET Core 集成测试 的文章，因为一旦说起单元测试这个话题，多多少少会牵动我内心深处的理想主义色彩，虽然如今已然是程序员职业生涯的第七年，可在我看来依然有太多东西在原地打转。这一路跌跌撞撞地走过来，在不同的公司里，见识到了形态各异的研发流程，接触到了貌合神离的敏捷思想，阅读过了风格迥异的框架/架构。当时间节点来到 2022 年，惊觉  诞生业已 20 周年，虽然技术一直在不断向前发展，可我个人感觉，我们并没有在工程化上取得多少感人的进步，譬如单元测试、需求管理，这些听起来丝
                                    　　软件的单元测试关注是的软件最小可执行单元是否能够正常执行，但是软件是由一个个最小执行单元组成的集合体，单元与单元之间存在着种种依赖或联系，所以在软件开发时仅仅确保最小单元的正确往往是不够的，为了保证软件能够正确运行，单元与单元之间的集成测试是非常必要。　　另外上一篇文章只是介绍了如何使用xUnit.net对.Net Core程序进行简单(无参)的单元测试以及计算代码的覆盖率，但是在实...
                                    本文需要您了解ASP.NET Core Web API 和 xUnit的相关知识.
这里有xUnit的介绍: https://www.cnblogs.com/cgzl/p/9178672.html#test
ASP.NET Core集成测试官方文档: https://docs.microsoft.com/en-us/aspnet/core/test/integration-tests?view...
                                    本文我们的目的是在我们构建我们应用程序的时候能够进行测试，如何使用XUnit结合你可以通过为你的项目添加不同的测试用例NSubstitute进行单元测试，同时对整个项目进行集成测试。
                                    6.8 ASP.NET Core6.8.1 简介这篇文档是对ABP中集成的ASP.NET Core的描述。ASP.NET 集成是被实现在 Abp.AspNetCore 中。
  迁移到ASP.NET Core?
  如果你有一个旧项目想要迁移到ASP.NET Core，你可以从该博客获取一些迁移经验
6.8.2 Startup Template你可以从Startup Template来创建你的
                                    集成测试用于检查应用程序的不同部分组装在一起时是否按预期工作。 使用集成测试时，您通常会希望跳过身份验证和授权测试。 例如，您可能对测试控制器方法更感兴趣，而不会妨碍身份验证和授权。 
 在本文中，我将讨论在ASP.Net Core中进行集成测试时如何绕过此类安全检查。 
 [InfoWorld的要点： CI / CD入门：使用CI / CD管道自动执行应用程序交付 。 • CI / CD的5...