"Go" writing high-quality Code 157 recommendations for improving C # Programs--Recommendation 155: Submit unit test code along with production code

Recommendation 155: Submit unit test code along with production code

Let's start with a question: Are we afraid to change the code? Have you ever faced a messy code, determined to refactor, and then received a report from the beta in Monday, one months later: The new version, with no previous version stability, worse performance, and bugs seem to have changed a lot. In other words, the refactoring code looks more quality, but the actual test results are unsatisfactory.

Almost every programmer has struggled with this sort of problem. The code we're trying to modify may come from some irresponsible or inexperienced programmer, perhaps written a year ago, but it looks like it's going to be awful. We wanted to modify the code, but we were afraid of refactoring something else. Even in a development cycle, there is a choice for the product. A module may have been submitted for testing and confirmed through, but now found that there are better algorithms and logic, change or not change, has become a problem.

Unit testing mitigates or even eliminates the fear of developers. If the project has no test code, it means we are only producing "time bombs". Many people treat production code and test code separately, which is an obsolete practice. When programmers submit their own production code, they must submit their own unit test code at the same time. Many modern version management tools can customize project build plans in the background, run test projects automatically, count code coverage, and generate reports accordingly. We should drink coffee in the morning and read such a report.

With the test code to make sure, to a large extent we can rest assured to refactor. If a feature deviates from the existing results, there is a noticeable reminder.

One of the development patterns that puts unit testing first is the TDD pattern. TDD (Test driven development testing-driven development) has three strict laws:

• Do not write any production code until you write a unit test that cannot pass the test.
• Write only unit tests that just can't be passed, not compile or pass.
• Write only the production code that is just enough to pass the current failure test.

Even if our team does not fully adopt TDD's development model, we can draw on these laws to write our own test code. We don't have to write all the test code at once, which is not necessary, as is the case with over-design. In fact, we should write the test code gradually, and follow the following steps to write:

Test code, Production Code, test code

An example of a unit test is written below:

Write an Add method first:

     Public class SampleClass    {        publicint Add (intint  b)        {            return A + b;        }    }

Right-click to create a unit test:

VS will automatically generate a test method for us:

        /// <summary>        ///test of Add///</summary>[TestMethod ()] Public voidaddtest () {SampleClass target=NewSampleClass ();//TODO: Initialize to the appropriate value            intA =0;//TODO: Initialize to the appropriate value            intb =0;//TODO: Initialize to the appropriate value            intexpected =0;//TODO: Initialize to the appropriate value            intactual; Actual=Target.            Add (A, b);            Assert.AreEqual (expected, actual); Assert.Inconclusive ("Verify the correctness of this test method. "); }

Modify the method to the method we need:

        ///<summary>///Test of ADD///</summary>[TestMethod ()]PublicvoidAddtest () {SampleClass target =New SampleClass ();// TODO: Initialize to the appropriate value int a = 1< Span style= "COLOR: #800080" >; // TODO: Initialize to the appropriate value int b = Span style= "COLOR: #800080" >2; // TODO: Initialize to the appropriate value int expected = 3; // TODO: Initialize to the appropriate value int actual; Actual = target. Add (A, b); Assert.AreEqual (expected, actual); Assert.Inconclusive ( " Verify the correctness of this test method.  "        

VS This visual testing tool is too heavyweight, making it too cumbersome and time-consuming to run test code during development. You can consider using the test tool testdriven.net, which is no longer described here.

A few points to note about unit testing:

First, unit testing should not introduce any human-computer interaction content. For example, a dialog box should not pop up during testing, waiting for the user to enter or confirm. Unit tests should not be blocked.

Second, multithreading is not part of the Unit testing category, unit testing should be executed quickly, rather than waiting.

Finally, unit tests should not cross application domains, for example, data access or remote communication is part of the integration testing category, not unit testing.

Turn from: 157 recommendations for writing high-quality code to improve C # programs Minjia

"Go" writing high-quality Code 157 recommendations for improving C # Programs--Recommendation 155: Submit unit test code along with production code