. NET programmers must be aware of the context Environment check during execution of integration test cases in the Dev environment. netdev

. NET programmers must be aware of the context Environment check during execution of integration test cases in the Dev environment. netdev

Microsoft. NET solution, required for project development.

From the beginning of this article, I will share a series of core technical points of. NET project development that I think are necessary in actual work. Although this series is used. NET/C #, but it is also applicable to other similar OO technology platforms. These technical points may not be fully described, but it is a summary of experience, it is the Awakening after many pitfalls, so it takes several minutes to remember it. In real project development, you will know how helpful it is. Now, let's get started with the theme.

During service development, we conduct a basic module test locally for debugging convenience. You can also think of it as an integration test, but your test cases won't cover more than 80%, instead, we think that appropriate use cases can be written to test it, rather than at ease during development.

Integration test cases usually have multiple execution contexts. For our developers, our execution contexts are usually local, and the testers are in the test environment. Tests by developers cannot be connected to other environments (of course, depending on the specific situation, some use cases are dangerous and cannot be connected randomly. This article will explain how to solve this problem ), all resources and services to be accessed in the integrated test cases run by developers are in the development environment. This still exists, but for debugging convenience, we still need to be able to connect to other environments for debugging as necessary, in order to simulate the problematic environment and real data, we need to have such a mechanism. When necessary, I can open a setting so that it can switch the environment context of the integrated test run, to put it bluntly, it is the connection address of the environment and data source that you want to connect.

In this article, we will use a simple example to learn how to simply handle this situation. This is actually based on the effect of testing for continuous refactoring.

 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 ProductServiceIntegrationTest13     {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 }

This is an actual integration test case code. There is a service address shared by the current test class, which is in the DEV environment. Of course, you can also define the service address of several other environments, the premise is that the environment allows you to connect.

Let's take a look at the test case. It is a query method test case for ProductServiceClient. the GetProductByPid service method is used for testing. Because the query-oriented operations are implemented on the same screen, no matter how many times we query the Product of this ID, it will not affect the data, however, if we test an update or delete operation, it will cause problems.

In the DEV environment, there is no problem in testing update and delete use cases. However, if your machine is able to connect to a remote production or PRD test, it may bring a certain risk, especially when you are busy, it is hard to remember whether the host configuration of your current machine is still connected to a remote production machine, or you don't need to configure the host to connect to an environment you shouldn't connect.

This is the current problem. So how can we solve this problem? by performing a simple reconstruction of the test code, we can avoid the danger of running the test case in the environment that should not be connected.

In fact, many times, Refactoring can really help us find the exit, as the saying goes: "The exit is turning around". Only continuous reconstruction can ensure the quality of the project gradually, this effect is rare.

Extract the abstract base class and define the environment to be accessed.

 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 } 

Eliminate repeated code for specific test classes and add a unified constructor.

 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 : ProductServiceIntegrationBase13     {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 } 

After code duplication is eliminated, we need to check whether a specific test case can be connected to an environment. I added a DeleteProductSearchIndex test case to test the deletion of search indexes, this test case can only be run in the local DEV environment (You may think that this Delete interface should not be put in this service. Here is just an example, so you don't need to worry about it ).

In order to have a check mechanism to remind developers of the current connection address, we need to use the test context.

After reconstruction, let's take a look at the current test code structure.

 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 : ProductServiceIntegrationBase13     {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 }

We have added an important test instance runtime method InitTestInstance, which will be executed before each test case is instantiated. There is an environment inside the method that is used to check the running of the current test case.
This. CheckCurrentTestCaseIsRun (this. serviceInstance); // check current test case., we will go to the base class.

1 using System; 2 using Microsoft. visual Studio. 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 Service AddressForPrd = "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 {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 environment, check 34 {35 if (this. testContext. testName. equals ("ProductService_DeleteProductSearchIndex_Test") 36 Assert. isTrue (false, "the current test case connection environment is PRD. Please stop running the current test case. "); 37} 38 else if (testObject. serviceAddress. equals (ServiceAddressTest) // Test environment, check the conventions for several use cases 39 {40 if (this. testContext. testName. equals ("ProductService_DeleteProductSearchIndex_Test") 41 Assert. isTrue (false, "the current TEST case connection environment is TEST. To avoid damaging the TEST environment, stop the use case. "); 42} 43} 44} 45}

In the check method, we use a simple method to judge that a use case cannot be executed in the PRD and TEST environments. Although the judgment is a bit simple, it is sufficient in real projects, simplicity is sometimes a design idea. We run all the test cases to view the status.

More importantly, it does not affect your execution of other use cases. When you troubleshoot the problem at midnight, it is difficult for you to control the big problems caused by the case execution errors caused by your own Vertigo or physical weakness, or even irreparable errors.

This article is dedicated to. NET programmers like me. Through simple refactoring, we have liberated ourselves.

 

Author: Wang qingpei

Source: http://www.cnblogs.com/wangiqngpei557/

The copyright of this article is shared by the author and the blog Park. You are welcome to reprint this article. However, you must keep this statement without the author's consent and go to the Article Page.