.NET程序员项目开发必知必会—Dev环境中的集成测试用例执行时上下文环境检查(实战)

简介:

Microsoft.NET 解决方案,项目开发必知必会。

从这篇文章开始我将分享一系列我认为在实际工作中很有必要的一些.NET项目开发的核心技术点,所以我称为必知必会。尽管这一些列是使用.NET/C#来展现,但是同样适用于其他类似的OO技术平台,这些技术点可能称不上完整的技术,但是它是经验的总结,是掉过多少坑之后的觉醒,所以有必要花几分钟时间记住它,在真实的项目开发中你就知道是多么的有帮助。好了,废话不说了,进入主题。

我们在开发服务时为了调试方便会在本地进行一个基本的模块测试,你也可以认为是集成测试,只不过你的测试用例不会覆盖到80%以上,而是一些我们认为在开发时不是很放心的点才会编写适当的用例来测试它。

集成测试用例通常有多个执行上下文,对于我们开发人员来说我们的执行上下文通常都在本地,测试人员的上下文在测试环境中。开发人员的测试用来是不能够连接到其他环境中去的(当然视具体情况而定,有些用例很危险是不能够乱连接的,本文会讲如何解决),开发人员运行的集成测试用例所要访问的所有资源、服务都是在开发环境中的。这里依然存在但是,但是为了调试方便,我们还是需要能够在必要的时候连接到其他环境中去调试问题,为了能够真实的模拟出问题的环境、可真实的数据,我们需要能有一个这样的机制,在需要的时候我能够打开某个设置让其能够切换集成测试运行的环境上下文,其实说白了就是你所要连接的环境、数据源的连接地址。

本篇文章我们将通过一个简单的实例来了解如何简单的处理这中情况,这其实基于对测试用来不断重构后的效果。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
using  System;
using  Microsoft.VisualStudio.TestTools.UnitTesting; 
 
namespace  OrderManager.Test
{
     using  ProductService.Contract; 
 
     /// <summary>
     /// Product service integration tests.
     /// </summary>
     [TestClass]
     public  class  ProductServiceIntegrationTest
     {
         /// <summary>
         /// service address.
         /// </summary>
         public  const  string  ServiceAddress =  "http://dev.service.ProductService/"
 
         /// <summary>
         /// Product service get product by pid test.
         /// </summary>
         [TestMethod]
         public  void  ProductService_GetProductByPid_Test()
         {
             var  serviceInstance = ProductServiceClient.CreateClient(ServiceAddress);
             var  testResult = serviceInstance.GetProductByPid(0393844); 
 
             Assert.AreNotEqual(testResult,  null );
             Assert.AreEqual(testResult.Pid, 0393844);
         }
     }
}

这是一个实际的集成测试用例代码,有一个当前测试类共用的服务地址,这个地址是DEV环境的,当然你也可以定义其他几个环境的服务地址,前提是环境是允许你连接的,那才有实际意义。

我们来看测试用例,它是一个查询方法测试用例,用来对ProductServiceClient.GetProductByPid服务方法进行测试,由于面向查询的操作是等幕的,不论我们查询多少次这个ID的Product,都不会对数据造成影响,但是如果我们测试的是一个更新或者删除就会带来问题。

在DEV环境中,测试更新、删除用例没有问题,但是如果你的机器是能够连接到远程某个生产或者PRD测试上时会带来一定的危险性,特别是在忙的时候,加班加点的干进度,你很难记住你当前的机器的host配置中是否还连接着远程的生产机器上,或者根本就不需要配置host就能够连接到某个你不应该连接的环境上。

这是目前的问题,那么我们如何解决这个问题呢 ,我们通过对测试代码进行一个简单的重构就可以避免由于连接到不该连接的环境中运行危险的测试用例。

其实很多时候,重构真的能够帮助我们找到出口,就好比俗话说的:"出口就在转角处“,只有不断重构才能够逐渐的保证项目的质量,而这种效果是很难得的。

提取抽象基类,对测试要访问的环境进行明确的定义。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
namespace  OrderManager.Test
{
     public  abstract  class  ProductServiceIntegrationBase
     {
         /// <summary>
         /// service address.
         /// </summary>
         protected  const  string  ServiceAddressForDev =  "http://dev.service.ProductService/"
 
         /// <summary>
         /// service address.
         /// </summary>
         protected  const  string  ServiceAddressForPrd =  "http://Prd.service.ProductService/"
 
         /// <summary>
         /// service address.
         /// </summary>
         protected  const  string  ServiceAddressTest =  "http://Test.service.ProductService/" ;
     }
}

对具体的测试类消除重复代码,加入统一的构造方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
using  System;
using  Microsoft.VisualStudio.TestTools.UnitTesting; 
 
namespace  OrderManager.Test
{
     using  ProductService.Contract; 
 
     /// <summary>
     /// Product service integration tests.
     /// </summary>
     [TestClass]
     public  class  ProductServiceIntegrationTest : ProductServiceIntegrationBase
     {
         /// <summary>
         /// product service client.
         /// </summary>
         private  ProductServiceClient serviceInstance; 
 
         /// <summary>
         /// Initialization test instance.
         /// </summary>
         [TestInitialize]
         public  void  InitTestInstance()
         {
             serviceInstance = ProductServiceClient.CreateClient(ServiceAddressForDev /*for dev*/ );
        
 
         /// <summary>
         /// Product service get product by pid test.
         /// </summary>
         [TestMethod]
         public  void  ProductService_GetProductByPid_Test()
         {
             var  testResult = serviceInstance.GetProductByPid(0393844); 
 
             Assert.AreNotEqual(testResult,  null );
             Assert.AreEqual(testResult.Pid, 0393844);
        
 
         /// <summary>
         /// Product service delete search index test.
         /// </summary>
         [TestMethod]
         public  void  ProductService_DeleteProductSearchIndex_Test()
         {
             var  testResult = serviceInstance.DeleteProductSearchIndex(); 
 
             Assert.IsTrue(testResult);
         }
     }
}

消除重复代码后,我们需要加入对具体测试用例检查是否能够连接到某个环境中去。我加入了一个DeleteProductSearchIndex测试用例,该用例是用来测试删除搜索索引的,这个测试用例只能够在本地DEV环境中运行(你可能觉得这个删除接口不应该放在这个服务里,这里只是举一个例子,无需纠结)。

为了能够有一个检查机制能提醒开发人员你目前连接的地址是哪一个,我们需要借助于测试上下文。

重构后,我们看一下现在的测试代码结构。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
using  System;
using  Microsoft.VisualStudio.TestTools.UnitTesting; 
 
namespace  OrderManager.Test
{
     using  ProductService.Contract; 
 
     /// <summary>
     /// Product service integration tests.
     /// </summary>
     [TestClass]
     public  class  ProductServiceIntegrationTest : ProductServiceIntegrationBase
     {
         /// <summary>
         /// product service client.
         /// </summary>
         private  ProductServiceClient serviceInstance; 
 
         /// <summary>
         /// Initialization test instance.
         /// </summary>
         [TestInitialize]
         public  void  InitTestInstance()
         {
             serviceInstance = ProductServiceClient.CreateClient(ServiceAddressForPrd /*for dev*/ ); 
 
             this .CheckCurrentTestCaseIsRun( this .serviceInstance); //check current test case .
        
 
         /// <summary>
         /// Product service get product by pid test.
         /// </summary>
         [TestMethod]
         public  void  ProductService_GetProductByPid_Test()
         {
             var  testResult = serviceInstance.GetProductByPid(0393844); 
 
             Assert.AreNotEqual(testResult,  null );
             Assert.AreEqual(testResult.Pid, 0393844);
        
 
         /// <summary>
         /// Product service delete search index test.
         /// </summary>
         [TestMethod]
         public  void  ProductService_DeleteProductSearchIndex_Test()
         {
             var  testResult = serviceInstance.DeleteProductSearchIndex(); 
 
             Assert.IsTrue(testResult);
         }
     }
}

我们加入了一个很重要的测试实例运行时方法InitTestInstance,该方法会在测试用例每次实例化时先执行,在方法内部有一个用来检查当前测试用例运行的环境 
this.CheckCurrentTestCaseIsRun(this.serviceInstance);//check current test case .,我们转到基类中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
using  System;
using  Microsoft.VisualStudio.TestTools.UnitTesting; 
 
namespace  OrderManager.Test
{
     public  abstract  class  ProductServiceIntegrationBase
     {
         /// <summary>
         /// service address.
         /// </summary>
         protected  const  string  ServiceAddressForDev =  "http://dev.service.ProductService/" ;
 
         /// <summary>
         /// get service address.
         /// </summary>
         protected  const  string  ServiceAddressForPrd =  "http://Prd.service.ProductService/" ;
 
         /// <summary>
         /// service address.
         /// </summary>
         protected  const  string  ServiceAddressTest =  "http://Test.service.ProductService/" ;
 
         /// <summary>
         /// Test context .
         /// </summary>
         public  TestContext TestContext {  get set ; } 
 
         /// <summary>
         /// is check is run for current test case.
         /// </summary>
         protected  void  CheckCurrentTestCaseIsRun(ProductService.Contract.ProductServiceClient testObject)
         {
             if  (testObject.ServiceAddress.Equals(ServiceAddressForPrd)) // Prd 环境,需要小心检查
             {
                 if  ( this .TestContext.TestName.Equals( "ProductService_DeleteProductSearchIndex_Test" ))
                     Assert.IsTrue( false "当前测试用例连接的环境为PRD,请停止当前用例的运行。" );
             }
             else  if  (testObject.ServiceAddress.Equals(ServiceAddressTest)) //Test 环境,检查约定几个用例
             {
                 if  ( this .TestContext.TestName.Equals( "ProductService_DeleteProductSearchIndex_Test" ))
                     Assert.IsTrue( false "当前测试用例连接的环境为TEST,为了不破坏TEST环境,请停止用例的运行。" );
             }
         }
     }
     
}

在检查方法中我们使用简单的判断某个用例不能够在PRD、TEST环境下执行,虽然判断有点简单,但是在真实的项目中足够了,简单有时候是一种设计思想。我们运行所有的测试用例,查看各个状态。

wKioL1QW2cOyd87PAAIr1ZdLOvg782.jpg

一目了然,更为重要的是它不会影响你对其他用例的执行。当你在深夜12点排查问题的时候,你很难控制自己的眼花、体虚导致的用例执行错误带来的大问题,甚至是无法挽回的的错误。

此文献给那些跟我一样的.NET程序员们,通过简单的重构,我们放开了自己。




 本文转自 王清培 51CTO博客,原文链接:http://blog.51cto.com/wangqingpei557/1553012,如需转载请自行联系原作者





相关文章
|
10月前
|
监控 安全 测试技术
【01】卓伊凡收到冒充税务机关的诈骗程序-决定在沙盒Sandbox环境中运行测试下-广大企业同胞们注意防诈骗
【01】卓伊凡收到冒充税务机关的诈骗程序-决定在沙盒Sandbox环境中运行测试下-广大企业同胞们注意防诈骗
268 14
【01】卓伊凡收到冒充税务机关的诈骗程序-决定在沙盒Sandbox环境中运行测试下-广大企业同胞们注意防诈骗
|
8月前
|
机器学习/深度学习 存储 算法
强化学习算法基准测试:6种算法在多智能体环境中的表现实测
本文系统研究了多智能体强化学习的算法性能与评估框架,选用井字棋和连珠四子作为基准环境,对比分析Q-learning、蒙特卡洛、Sarsa等表格方法在对抗场景中的表现。实验表明,表格方法在小规模状态空间(如井字棋)中可有效学习策略,但在大规模状态空间(如连珠四子)中因泛化能力不足而失效,揭示了向函数逼近技术演进的必要性。研究构建了标准化评估流程,明确了不同算法的适用边界,为理解强化学习的可扩展性问题提供了实证支持与理论参考。
413 0
强化学习算法基准测试:6种算法在多智能体环境中的表现实测
|
10月前
|
数据采集 自然语言处理 Java
Playwright 多语言一体化——Python/Java/.NET 全栈采集实战
本文以反面教材形式,剖析了在使用 Playwright 爬取懂车帝车友圈问答数据时常见的配置错误(如未设置代理、Cookie 和 User-Agent),并提供了 Python、Java 和 .NET 三种语言的修复代码示例。通过错误示例 → 问题剖析 → 修复过程 → 总结教训的完整流程,帮助读者掌握如何正确配置爬虫代理及其它必要参数,避免 IP 封禁和反爬检测,实现高效数据采集与分析。
624 3
Playwright 多语言一体化——Python/Java/.NET 全栈采集实战
|
存储 人工智能 编译器
【03】鸿蒙实战应用开发-华为鸿蒙纯血操作系统Harmony OS NEXT-测试hello word效果-虚拟华为手机真机环境调试-为DevEco Studio编译器安装中文插件-测试写一个滑动块效果-介绍诸如ohos.ui等依赖库-全过程实战项目分享-从零开发到上线-优雅草卓伊凡
【03】鸿蒙实战应用开发-华为鸿蒙纯血操作系统Harmony OS NEXT-测试hello word效果-虚拟华为手机真机环境调试-为DevEco Studio编译器安装中文插件-测试写一个滑动块效果-介绍诸如ohos.ui等依赖库-全过程实战项目分享-从零开发到上线-优雅草卓伊凡
886 11
【03】鸿蒙实战应用开发-华为鸿蒙纯血操作系统Harmony OS NEXT-测试hello word效果-虚拟华为手机真机环境调试-为DevEco Studio编译器安装中文插件-测试写一个滑动块效果-介绍诸如ohos.ui等依赖库-全过程实战项目分享-从零开发到上线-优雅草卓伊凡
|
人工智能 JSON 自然语言处理
AI 程序员的4个分身 | 代码生成专家+注释精灵+API集成助手+智能调试伙伴
AI 程序员的4个分身 | 代码生成专家+注释精灵+API集成助手+智能调试伙伴
516 35
|
缓存 Java 测试技术
【01】噩梦终结flutter配安卓android鸿蒙harmonyOS 以及next调试环境配鸿蒙和ios真机调试环境-flutter项目安卓环境配置-gradle-agp-ndkVersion模拟器运行真机测试环境-本地环境搭建-如何快速搭建android本地运行环境-优雅草卓伊凡-很多人在这步就被难倒了
【01】噩梦终结flutter配安卓android鸿蒙harmonyOS 以及next调试环境配鸿蒙和ios真机调试环境-flutter项目安卓环境配置-gradle-agp-ndkVersion模拟器运行真机测试环境-本地环境搭建-如何快速搭建android本地运行环境-优雅草卓伊凡-很多人在这步就被难倒了
1818 3
【01】噩梦终结flutter配安卓android鸿蒙harmonyOS 以及next调试环境配鸿蒙和ios真机调试环境-flutter项目安卓环境配置-gradle-agp-ndkVersion模拟器运行真机测试环境-本地环境搭建-如何快速搭建android本地运行环境-优雅草卓伊凡-很多人在这步就被难倒了
|
域名解析 弹性计算 监控
slb测试基本配置检查
slb测试基本配置检查
353 60
|
开发框架 搜索推荐 算法
一个包含了 50+ C#/.NET编程技巧实战练习教程
一个包含了 50+ C#/.NET编程技巧实战练习教程
458 18
|
机器学习/深度学习 人工智能 算法
BALROG:基准测试工具,用于评估 LLMs 和 VLMs 在复杂动态环境中的推理能力
BALROG 是一款用于评估大型语言模型(LLMs)和视觉语言模型(VLMs)在复杂动态环境中推理能力的基准测试工具。它通过一系列挑战性的游戏环境,如 NetHack,测试模型的规划、空间推理和探索能力。BALROG 提供了一个开放且细粒度的评估框架,推动了自主代理研究的进展。
472 3
BALROG:基准测试工具,用于评估 LLMs 和 VLMs 在复杂动态环境中的推理能力
|
算法 Java 测试技术
使用 BenchmarkDotNet 对 .NET 代码进行性能基准测试
使用 BenchmarkDotNet 对 .NET 代码进行性能基准测试
386 13