. 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.

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 duplicate code for specific test classes and join a unified construction method.

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 ()          {&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBsp;      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 =  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]   &nBsp;    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. Inside the method, there is an environment
this that checks for the current test case to 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>        /// is check  is run for current test case.        // / </summary&gT;        protected void checkcurrenttestcaseisrun ( Productservice.contract.productserviceclient testobject)         {             if  ( TestObject.ServiceAddress.Equals (SERVICEADDRESSFORPRD))// prd  environment, requires careful inspection              {                 if  (this. TestContext.TestName.Equals ("Productservice_deleteproductsearchindex_test"))                      assert.istrue (False,   "The current test case connection environment is PRD, stop running the current use case. ");            }             else if  (TESTOBJECT.SERVICEADDRESS.EQuals (serviceaddresstest))//test  Environment, check conventions several use cases              {                 if  (this. TestContext.TestName.Equals ("Productservice_deleteproductsearchindex_test"))                      assert.istrue (False,   "The current test case is connected to test and, in order not to break the test environment, stop the use case." ");            }         }    }    }

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.

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M01/49/A0/wKioL1QW2cOyd87PAAIr1ZdLOvg782.jpg "title=" 1.png " alt= "Wkiol1qw2coyd87paair1zdlovg782.jpg"/>

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, we let go of ourselves.

King Qingyue Culture

Source:http://wangqingpei557.blog.51cto.com/

This article is copyright to the author and 51CTO shared, welcome reprint, but without the consent of the author must retain this paragraph, and in the article page obvious location to the original link, otherwise reserves the right to pursue legal responsibility.

This article from the "humble if foolish, thirst for knowledge" blog, please be sure to keep this source http://wangqingpei557.blog.51cto.com/1009349/1553012

. 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)