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

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

创新互联专注于古浪企业网站建设,响应式网站开发,成都商城网站开发。古浪网站建设公司,为古浪等地区提供建站服务。全流程按需定制，专业设计，全程项目跟踪，创新互联专业和态度为您提供的服务

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

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

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

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

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting; 

namespace OrderManager.Test
{
    using ProductService.Contract; 

    /// 

    /// Product service integration tests.
    /// 
    [TestClass]
    public class ProductServiceIntegrationTest
    {
        /// 

        /// service address.
        /// 
        public const string ServiceAddress = "http://dev.service.ProductService/"; 

        /// 

        /// Product service get product by pid test.
        /// 
        [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就能够连接到某个你不应该连接的环境上。

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

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

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

namespace OrderManager.Test
{
    public abstract class ProductServiceIntegrationBase
    {
        /// 

        /// service address.
        /// 
        protected const string ServiceAddressForDev = "http://dev.service.ProductService/"; 

        /// 

        /// service address.
        /// 
        protected const string ServiceAddressForPrd = "http://Prd.service.ProductService/"; 

        /// 

        /// service address.
        /// 
        protected const string ServiceAddressTest = "http://Test.service.ProductService/";
    }
}

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

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting; 

namespace OrderManager.Test
{
    using ProductService.Contract; 

    /// 

    /// Product service integration tests.
    /// 
    [TestClass]
    public class ProductServiceIntegrationTest : ProductServiceIntegrationBase
    {
        /// 

        /// product service client.
        /// 
        private ProductServiceClient serviceInstance; 

        /// 

        /// Initialization test instance.
        /// 
        [TestInitialize]
        public void InitTestInstance()
        {
            serviceInstance = ProductServiceClient.CreateClient(ServiceAddressForDev/*for dev*/);
        } 

        /// 

        /// Product service get product by pid test.
        /// 
        [TestMethod]
        public void ProductService_GetProductByPid_Test()
        {
            var testResult = serviceInstance.GetProductByPid(0393844); 

            Assert.AreNotEqual(testResult, null);
            Assert.AreEqual(testResult.Pid, 0393844);
        } 

        /// 

        /// Product service delete search index test.
        /// 
        [TestMethod]
        public void ProductService_DeleteProductSearchIndex_Test()
        {
            var testResult = serviceInstance.DeleteProductSearchIndex(); 

            Assert.IsTrue(testResult);
        }
    }
}

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

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

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

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting; 

namespace OrderManager.Test
{
    using ProductService.Contract; 

    /// 

    /// Product service integration tests.
    /// 
    [TestClass]
    public class ProductServiceIntegrationTest : ProductServiceIntegrationBase
    {
        /// 

        /// product service client.
        /// 
        private ProductServiceClient serviceInstance; 

        /// 

        /// Initialization test instance.
        /// 
        [TestInitialize]
        public void InitTestInstance()
        {
            serviceInstance = ProductServiceClient.CreateClient(ServiceAddressForPrd/*for dev*/); 

            this.CheckCurrentTestCaseIsRun(this.serviceInstance);//check current test case .
        } 

        /// 

        /// Product service get product by pid test.
        /// 
        [TestMethod]
        public void ProductService_GetProductByPid_Test()
        {
            var testResult = serviceInstance.GetProductByPid(0393844); 

            Assert.AreNotEqual(testResult, null);
            Assert.AreEqual(testResult.Pid, 0393844);
        } 

        /// 

        /// Product service delete search index test.
        /// 
        [TestMethod]
        public void ProductService_DeleteProductSearchIndex_Test()
        {
            var testResult = serviceInstance.DeleteProductSearchIndex(); 

            Assert.IsTrue(testResult);
        }
    }
}

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

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting; 

namespace OrderManager.Test
{
    public abstract class ProductServiceIntegrationBase
    {
        /// 

        /// service address.
        /// 
        protected const string ServiceAddressForDev = "http://dev.service.ProductService/";

        /// 

        /// get service address.
        /// 
        protected const string ServiceAddressForPrd = "http://Prd.service.ProductService/";

        /// 

        /// service address.
        /// 
        protected const string ServiceAddressTest = "http://Test.service.ProductService/";

        /// 

        /// Test context .
        /// 
        public TestContext TestContext { get; set; } 

        /// 

        /// is check is run for current test case.
        /// 
        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环境下执行，虽然判断有点简单，但是在真实的项目中足够了，简单有时候是一种设计思想。我们运行所有的测试用例，查看各个状态。

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

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

作者：王清培

出处：http://wangqingpei557.blog.51cto.com/

本文版权归作者和51CTO共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。