Dev环境中的集成测试用例执行时上下文环境检查

简介:
我们在开发服务时为了调试方便会在本地进行一个基本的模块 测试,你也可以认为是 集成测试,只不过你的 测试用例不会覆盖到80%以上,而是一些我们认为在开发时不是很放心的点才会编写适当的用例来测试它。
  集成测试用例通常有多个执行上下文,对于我们开发人员来说我们的执行上下文通常都在本地,测试人员的上下文在测试环境中。开发人员的测试用来是不能够连接到其他环境中去的(当然视具体情况而定,有些用例很危险是不能够乱连接的,本文会讲如何解决),开发人员运行的集成测试用例所要访问的所有资源、服务都是在开发环境中的。这里依然存在但是,但是为了调试方便,我们还是需要能够在必要的时候连接到其他环境中去调试问题,为了能够真实的模拟出问题的环境、可真实的数据,我们需要能有一个这样的机制,在需要的时候我能够打开某个设置让其能够切换集成测试运行的环境上下文,其实说白了就是你所要连接的环境、数据源的连接地址。
  本篇 文章我们将通过一个简单的实例来了解如何简单的处理这中情况,这其实基于对测试用来不断重构后的效果。
1 using System;
2 using Microsoft.VisualStudio.TestTools.UnitTesting;
3
4 namespace OrderManager.Test
5 {
6     using ProductService.Contract;
7
8     /// <summary>
9     /// Product service integration tests.
10     /// </summary>
11     [TestClass]
12     public class ProductServiceIntegrationTest
13     {
14         /// <summary>
15         /// service address.
16         /// </summary>
17         public const string ServiceAddress = "http://dev.service.ProductService/";
18
19         /// <summary>
20         /// Product service get product by pid  test.
21         /// </summary>
22         [TestMethod]
23         public void ProductService_GetProductByPid_Test()
24         {
25             var serviceInstance = ProductServiceClient.CreateClient(ServiceAddress);
26             var testResult = serviceInstance.GetProductByPid(0393844);
27
28             Assert.AreNotEqual(testResult, null);
29             Assert.AreEqual(testResult.Pid, 0393844);
30         }
31     }
32 }
  这是一个实际的集成测试用例代码,有一个当前测试类共用的服务地址,这个地址是DEV环境的,当然你也可以定义其他几个环境的服务地址,前提是环境是允许你连接的,那才有实际意义。
  我们来看测试用例,它是一个查询方法测试用例,用来对ProductServiceClient.GetProductByPid服务方法进行测试,由于面向查询的操作是等幕的,不论我们查询多少次这个ID的Product,都不会对数据造成影响,但是如果我们测试的是一个更新或者删除就会带来问题。
  在DEV环境中,测试更新、删除用例没有问题,但是如果你的机器是能够连接到远程某个生产或者PRD测试上时会带来一定的危险性,特别是在忙的时候,加班加点的干进度,你很难记住你当前的机器的host配置中是否还连接着远程的生产机器上,或者根本就不需要配置host就能够连接到某个你不应该连接的环境上。
  这是目前的问题,那么我们如何解决这个问题呢 ,我们通过对测试代码进行一个简单的重构就可以避免由于连接到不该连接的环境中运行危险的测试用例。
其实很多时候,重构真的能够帮助我们找到出口,就好比俗话说的:"出口就在转角处“,只有不断重构才能够逐渐的保证项目的质量,而这种效果是很难得的。
  提取抽象基类,对测试要访问的环境进行明确的定义。
1 namespace OrderManager.Test
2 {
3     public abstract class ProductServiceIntegrationBase
4     {
5         /// <summary>
6         /// service address.
7         /// </summary>
8         protected const string ServiceAddressForDev = "http://dev.service.ProductService/";
9
10         /// <summary>
11         /// service address.
12         /// </summary>
13         protected const string ServiceAddressForPrd = "http://Prd.service.ProductService/";
14
15         /// <summary>
16         /// service address.
17         /// </summary>
18         protected const string ServiceAddressTest = "http://Test.service.ProductService/";
19     }
20 }
  对具体的测试类消除重复代码,加入统一的构造方法。
1 using System;
2 using Microsoft.VisualStudio.TestTools.UnitTesting;
3
4 namespace OrderManager.Test
5 {
6     using ProductService.Contract;
7
8     /// <summary>
9     /// Product service integration tests.
10     /// </summary>
11     [TestClass]
12     public class ProductServiceIntegrationTest : ProductServiceIntegrationBase
13     {
14         /// <summary>
15         /// product service client.
16         /// </summary>
17         private ProductServiceClient serviceInstance;
18
19         /// <summary>
20         /// Initialization test instance.
21         /// </summary>
22         [TestInitialize]
23         public void InitTestInstance()
24         {
25             serviceInstance = ProductServiceClient.CreateClient(ServiceAddressForDev/*for dev*/);
26         }
27
28         /// <summary>
29         /// Product service get product by pid test.
30         /// </summary>
31         [TestMethod]
32         public void ProductService_GetProductByPid_Test()
33         {
34             var testResult = serviceInstance.GetProductByPid(0393844);
35
36             Assert.AreNotEqual(testResult, null);
37             Assert.AreEqual(testResult.Pid, 0393844);
38         }
39
40         /// <summary>
41         /// Product service delete search index test.
42         /// </summary>
43         [TestMethod]
44         public void ProductService_DeleteProductSearchIndex_Test()
45         {
46             var testResult = serviceInstance.DeleteProductSearchIndex();
47
48             Assert.IsTrue(testResult);
49         }
50     }
51 }
  消除重复代码后,我们需要加入对具体测试用例检查是否能够连接到某个环境中去。我加入了一个DeleteProductSearchIndex测试用例,该用例是用来测试删除搜索索引的,这个测试用例只能够在本地DEV环境中运行(你可能觉得这个删除接口不应该放在这个服务里,这里只是举一个例子,无需纠结)。
  为了能够有一个检查机制能提醒开发人员你目前连接的地址是哪一个,我们需要借助于测试上下文。
  重构后,我们看一下现在的测试代码结构。
1 using System;
2 using Microsoft.VisualStudio.TestTools.UnitTesting;
3
4 namespace OrderManager.Test
5 {
6     using ProductService.Contract;
7
8     /// <summary>
9     /// Product service integration tests.
10     /// </summary>
11     [TestClass]
12     public class ProductServiceIntegrationTest : ProductServiceIntegrationBase
13     {
14         /// <summary>
15         /// product service client.
16         /// </summary>
17         private ProductServiceClient serviceInstance;
18
19         /// <summary>
20         /// Initialization test instance.
21         /// </summary>
22         [TestInitialize]
23         public void InitTestInstance()
24         {
25             serviceInstance = ProductServiceClient.CreateClient(ServiceAddressForPrd/*for dev*/);
26
27             this.CheckCurrentTestCaseIsRun(this.serviceInstance);//check current test case .
28         }
29
30         /// <summary>
31         /// Product service get product by pid test.
32         /// </summary>
33         [TestMethod]
34         public void ProductService_GetProductByPid_Test()
35         {
36             var testResult = serviceInstance.GetProductByPid(0393844);
37
38             Assert.AreNotEqual(testResult, null);
39             Assert.AreEqual(testResult.Pid, 0393844);
40         }
41
42         /// <summary>
43         /// Product service delete search index test.
44         /// </summary>
45         [TestMethod]
46         public void ProductService_DeleteProductSearchIndex_Test()
47         {
48             var testResult = serviceInstance.DeleteProductSearchIndex();
49
50             Assert.IsTrue(testResult);
51         }
52     }
53 }
我们加入了一个很重要的测试实例运行时方法InitTestInstance,该方法会在测试用例每次实例化时先执行,在方法内部有一个用来检查当前测试用例运行的环境
  this.CheckCurrentTestCaseIsRun(this.serviceInstance);//check current test case .,我们转到基类中。
1 using System;
2 using Microsoft.VisualStudio.TestTools.UnitTesting;
3
4 namespace OrderManager.Test
5 {
6     public abstract class ProductServiceIntegrationBase
7     {
8         /// <summary>
9         /// service address.
10         /// </summary>
11         protected const string ServiceAddressForDev = "http://dev.service.ProductService/";
12
13         /// <summary>
14         /// get service address.
15         /// </summary>
16         protected const string ServiceAddressForPrd = "http://Prd.service.ProductService/";
17
18         /// <summary>
19         /// service address.
20         /// </summary>
21         protected const string ServiceAddressTest = "http://Test.service.ProductService/";
22
23         /// <summary>
24         /// Test context .
25         /// </summary>
26         public TestContext TestContext { get; set; }
27
28         /// <summary>
29         /// is check is run for current test case.
30         /// </summary>
31         protected void CheckCurrentTestCaseIsRun(ProductService.Contract.ProductServiceClient testObject)
32         {
33             if (testObject.ServiceAddress.Equals(ServiceAddressForPrd))// Prd 环境,需要小心检查
34             {
35                 if (this.TestContext.TestName.Equals("ProductService_DeleteProductSearchIndex_Test"))
36                     Assert.IsTrue(false, "当前测试用例连接的环境为PRD,请停止当前用例的运行。");
37             }
38             else if (testObject.ServiceAddress.Equals(ServiceAddressTest))//Test 环境,检查约定几个用例
39             {
40                 if (this.TestContext.TestName.Equals("ProductService_DeleteProductSearchIndex_Test"))
41                     Assert.IsTrue(false, "当前测试用例连接的环境为TEST,为了不破坏TEST环境,请停止用例的运行。");
42             }
43         }
44     }
45 }
  在检查方法中我们使用简单的判断某个用例不能够在PRD、TEST环境下执行,虽然判断有点简单,但是在真实的项目中足够了,简单有时候是一种设计思想。我们运行所有的测试用例,查看各个状态。
  一目了然,更为重要的是它不会影响你对其他用例的执行。当你在深夜12点排查问题的时候,你很难控制自己的眼花、体虚导致的用例执行错误带来的大问题,甚至是无法挽回的的错误。

最新内容请见作者的GitHub页:http://qaseven.github.io/ 
相关文章
|
9月前
|
监控 安全 测试技术
【01】卓伊凡收到冒充税务机关的诈骗程序-决定在沙盒Sandbox环境中运行测试下-广大企业同胞们注意防诈骗
【01】卓伊凡收到冒充税务机关的诈骗程序-决定在沙盒Sandbox环境中运行测试下-广大企业同胞们注意防诈骗
246 14
【01】卓伊凡收到冒充税务机关的诈骗程序-决定在沙盒Sandbox环境中运行测试下-广大企业同胞们注意防诈骗
|
7月前
|
机器学习/深度学习 存储 算法
强化学习算法基准测试:6种算法在多智能体环境中的表现实测
本文系统研究了多智能体强化学习的算法性能与评估框架,选用井字棋和连珠四子作为基准环境,对比分析Q-learning、蒙特卡洛、Sarsa等表格方法在对抗场景中的表现。实验表明,表格方法在小规模状态空间(如井字棋)中可有效学习策略,但在大规模状态空间(如连珠四子)中因泛化能力不足而失效,揭示了向函数逼近技术演进的必要性。研究构建了标准化评估流程,明确了不同算法的适用边界,为理解强化学习的可扩展性问题提供了实证支持与理论参考。
382 0
强化学习算法基准测试:6种算法在多智能体环境中的表现实测
|
9月前
|
人工智能 安全 Shell
Jupyter MCP服务器部署实战:AI模型与Python环境无缝集成教程
Jupyter MCP服务器基于模型上下文协议(MCP),实现大型语言模型与Jupyter环境的无缝集成。它通过标准化接口,让AI模型安全访问和操作Jupyter核心组件,如内核、文件系统和终端。本文深入解析其技术架构、功能特性及部署方法。MCP服务器解决了传统AI模型缺乏实时上下文感知的问题,支持代码执行、变量状态获取、文件管理等功能,提升编程效率。同时,严格的权限控制确保了安全性。作为智能化交互工具,Jupyter MCP为动态计算环境与AI模型之间搭建了高效桥梁。
620 2
Jupyter MCP服务器部署实战:AI模型与Python环境无缝集成教程
|
11月前
|
人工智能 自然语言处理 文字识别
解读 | 金融长上下文基准测试FailSafeQA:解锁金融领域LLM真实的审慎性和容错性
近年来,大型语言模型(LLMs)在金融领域的应用如火如荼,从风险分析到客户服务,它们正逐步改变行业的游戏规则。然而,这些模型是否真的足够“靠谱”?面对复杂的金融数据和多变的用户输入,它们还能保持精准和稳健吗?
288 8
解读 | 金融长上下文基准测试FailSafeQA:解锁金融领域LLM真实的审慎性和容错性
|
12月前
|
存储 人工智能 编译器
【03】鸿蒙实战应用开发-华为鸿蒙纯血操作系统Harmony OS NEXT-测试hello word效果-虚拟华为手机真机环境调试-为DevEco Studio编译器安装中文插件-测试写一个滑动块效果-介绍诸如ohos.ui等依赖库-全过程实战项目分享-从零开发到上线-优雅草卓伊凡
【03】鸿蒙实战应用开发-华为鸿蒙纯血操作系统Harmony OS NEXT-测试hello word效果-虚拟华为手机真机环境调试-为DevEco Studio编译器安装中文插件-测试写一个滑动块效果-介绍诸如ohos.ui等依赖库-全过程实战项目分享-从零开发到上线-优雅草卓伊凡
807 11
【03】鸿蒙实战应用开发-华为鸿蒙纯血操作系统Harmony OS NEXT-测试hello word效果-虚拟华为手机真机环境调试-为DevEco Studio编译器安装中文插件-测试写一个滑动块效果-介绍诸如ohos.ui等依赖库-全过程实战项目分享-从零开发到上线-优雅草卓伊凡
|
12月前
|
缓存 Java 测试技术
【01】噩梦终结flutter配安卓android鸿蒙harmonyOS 以及next调试环境配鸿蒙和ios真机调试环境-flutter项目安卓环境配置-gradle-agp-ndkVersion模拟器运行真机测试环境-本地环境搭建-如何快速搭建android本地运行环境-优雅草卓伊凡-很多人在这步就被难倒了
【01】噩梦终结flutter配安卓android鸿蒙harmonyOS 以及next调试环境配鸿蒙和ios真机调试环境-flutter项目安卓环境配置-gradle-agp-ndkVersion模拟器运行真机测试环境-本地环境搭建-如何快速搭建android本地运行环境-优雅草卓伊凡-很多人在这步就被难倒了
1715 3
【01】噩梦终结flutter配安卓android鸿蒙harmonyOS 以及next调试环境配鸿蒙和ios真机调试环境-flutter项目安卓环境配置-gradle-agp-ndkVersion模拟器运行真机测试环境-本地环境搭建-如何快速搭建android本地运行环境-优雅草卓伊凡-很多人在这步就被难倒了
|
机器学习/深度学习 人工智能 算法
BALROG:基准测试工具,用于评估 LLMs 和 VLMs 在复杂动态环境中的推理能力
BALROG 是一款用于评估大型语言模型(LLMs)和视觉语言模型(VLMs)在复杂动态环境中推理能力的基准测试工具。它通过一系列挑战性的游戏环境,如 NetHack,测试模型的规划、空间推理和探索能力。BALROG 提供了一个开放且细粒度的评估框架,推动了自主代理研究的进展。
436 3
BALROG:基准测试工具,用于评估 LLMs 和 VLMs 在复杂动态环境中的推理能力
|
存储 Prometheus 运维
在云原生环境中,阿里云ARMS与Prometheus的集成提供了强大的应用实时监控解决方案
在云原生环境中,阿里云ARMS与Prometheus的集成提供了强大的应用实时监控解决方案。该集成结合了ARMS的基础设施监控能力和Prometheus的灵活配置及社区支持,实现了全面、精准的系统状态、性能和错误监控,提升了应用的稳定性和管理效率。通过统一的数据视图和高级查询功能,帮助企业有效应对云原生挑战,促进业务的持续发展。
354 3
|
缓存 Ubuntu Linux
Linux环境下测试服务器的DDR5内存性能
通过使用 `memtester`和 `sysbench`等工具,可以有效地测试Linux环境下服务器的DDR5内存性能。这些工具不仅可以评估内存的读写速度,还可以检测内存中的潜在问题,帮助确保系统的稳定性和性能。通过合理配置和使用这些工具,系统管理员可以深入了解服务器内存的性能状况,为系统优化提供数据支持。
1207 4
|
机器学习/深度学习 自然语言处理 前端开发
前端神经网络入门:Brain.js - 详细介绍和对比不同的实现 - CNN、RNN、DNN、FFNN -无需准备环境打开浏览器即可测试运行-支持WebGPU加速
本文介绍了如何使用 JavaScript 神经网络库 **Brain.js** 实现不同类型的神经网络,包括前馈神经网络(FFNN)、深度神经网络(DNN)和循环神经网络(RNN)。通过简单的示例和代码,帮助前端开发者快速入门并理解神经网络的基本概念。文章还对比了各类神经网络的特点和适用场景,并简要介绍了卷积神经网络(CNN)的替代方案。
1966 1

热门文章

最新文章