. NET programmer project Development must be aware of the-DEV environment in the context of integration test case execution when the environment check (actual combat)

Microsoft.NET Solutions, project development must be known.

From the beginning of this article I will share a series of things that I think are necessary in practical work. NET project development core technology, so I called must know. Although some of these columns are presented using. net/c#, the same applies to other similar OO technology platforms, which may not be a complete technology, but it is a summary of experience, the awakening of many pits, so it is necessary to spend a few minutes remembering it, You know how helpful it is in real-world project development. Okay, nonsense, go to the subject.

When we develop the service for debugging convenience, we will do a basic module testing locally, you can also think of integration testing, but your test cases will not cover more than 80%, but some we think at the development of the point is not very reassuring to write the appropriate use cases to test it.

Integration test cases often have multiple execution contexts, and for our developers our execution context is usually local, and the tester's context is in the test environment. Developers ' tests are used to not be able to connect to other environments (depending on the situation, some use cases are dangerous to be disconnected, this article will talk about how to resolve them), and all the resources and services that developers run for integration test cases are in the development environment. This still exists but, for debugging convenience, we still need to be able to connect to other environments when necessary to debug problems, in order to realistically simulate the problem of the environment, can be real data, we need to have a mechanism, When needed, I was able to open a setting that could switch the context of the integration test run, in fact, the environment you want to connect to, the connection address of the data source.

In this article we will use a simple example to understand how to handle this situation in a simple way, which is based on the effect of testing for continuous refactoring.

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); }    }}

This is an actual integration test case code, there is a current test class shared service address, this address is the dev environment, of course, you can also define a number of other environment service address, if the environment is allowed to connect, it is meaningful.

Let's look at the test case, which is a query method test case, Used to test the Productserviceclient.getproductbypid service method, because the query-oriented operation is a screen, no matter how many times we query the ID of the product, will not affect the data, but if we are testing an update or delete will cause problems.

In the dev environment, there is no problem with testing updates, deleting use cases, but if your machine is capable of connecting to a remote production or PRD test, it poses a risk, especially when busy, overtime work, It's hard to remember whether your current machine's host configuration is still connected to a remote production machine, or you don't need to configure host to connect to an environment that you shouldn't be connected to.

This is the current problem, so how do we solve this problem, we can avoid running dangerous test cases by connecting to the disconnected environment by a simple refactoring of the test code.

In fact, many times, refactoring can really help us to find exports, as the saying goes: "Export is at the corner", only the continuous reconstruction can gradually guarantee the quality of the project, and this effect is very rare.

Extracts the abstract base class and defines the environment to which the test is to be accessed.

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/";    

eliminate duplication of code for specific test classes and join a unified construction approach.

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 = P        Roductserviceclient.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);  }    }}

After eliminating the duplication of code, we need to join in checking the specific test cases to see if we can connect to an environment. I joined a deleteproductsearchindex test case, which is used to test the removal of the search index, which can only be run in the local dev environment (you might think that the delete interface should not be placed in this service, just to cite an example, no need to tangle).

In order to be able to have a check mechanism to remind the developer of which address you are currently connected to, we need to use the test context.

After refactoring, let's look at the current test code structure.

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 = P             Roductserviceclient.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); }    }}

we have added a very important test instance run-time method Inittestinstance, which is executed each time the test case is instantiated, and there is an environment inside the method that checks for the current test case run. Checkcurrenttestcaseisrun (this.serviceinstance);//check current test case., we go to the base class.

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>/AM Check is the run for current test case. </summary> protected void Checkcurrenttestcaseisrun (ProductService.Contract.ProductSerViceclient testobject) {if (TestObject.ServiceAddress.Equals (SERVICEADDRESSFORPRD))//PRD environment, need to be carefully checked {if (this. TestContext.TestName.Equals ("Productservice_deleteproductsearchindex_test")) Assert.istrue (False, "current test If the context of the use case connection is PRD, stop the current use case from running.            ");                } else if (TestObject.ServiceAddress.Equals (serviceaddresstest))//test Environment, check conventions for several use cases { if (this. TestContext.TestName.Equals ("Productservice_deleteproductsearchindex_test")) Assert.istrue (False, "current test The use case connection is test, and in order to not break the test environment, stop the use case from running.            "); }        }    }}

In the inspection method we use simple to determine that a use case can not be executed in the PRD, test environment, although the judgment is a bit simple, but in the real project is enough, simple is sometimes a design idea. We run all of the test cases and look at each state.

At a glance, it is more important that it does not affect your execution of other use cases. When you troubleshoot problems in the middle of the night 12 o'clock, it's hard to control your own vertigo, the big problems caused by use case execution errors, or even irreparable errors.

This document is for the same as me. NET programmers, through simple refactoring, liberated themselves.

. NET programmer project Development must be aware of the-DEV environment in the context of integration test case execution when the environment check (actual combat)