How many unit tests in TDD are written enough

Test-driven Development (TDD) is already a familiar noun, and since it is a test driver, the test case code will be written in front of the development code. But how do you write test cases? How many test cases are you writing enough? I think we all have this kind of doubt in the actual operation process.

March 15, I participated in the ThoughtWorks organization's "pair programming and TDD openworkshop" activity, listened to the Tong2 key of TW's senior consultant, and took part in the process of TDD and pair programming under the leadership of the instructor. In the event, the 仝键 teacher gave the following explanation to the question of how many test cases were written:

One of the important reasons we write unit tests is to prevent ourselves from making low-level mistakes. We cannot regard the people who write the implementation code as our enemies, but we must measure all the circumstances to prevent them from deliberately leaving hidden traps. No amount of testing can be written to cover the whole situation, so just make yourself feel safe. How can you make yourself feel safe? This is no standard answer, can only be written more after the test slowly experience.

In addition, it takes time to write a test, such as compare the implementation part of this method, we have only spent a two minutes to write, and these test code, we spent a good half an hour, this is worth it? For simple business logic, of course, it is not worthwhile, after all, we still have a lot of work to do, the boss spend money for our product code, not the test code.

Then consider a situation, I want to start a business, think of an idea, do a website, I certainly want to be the fastest speed to make it into a molding for others to use. If I do not know that people will not like the time, first spend a lot of time to write tests, and finally found that no one can only throw away, these tests are not written in vain.

So the above sentence: unit test is to let you improve your confidence in the code, as long as you feel safe to continue to develop when it is enough, not the more the better.

I believe that the above explanation has no objection to the questions raised in this article. But here we do not consider the special situation, in the actual operation, whether there is a way to measure the work of unit testing? To judge if it's enough?

Use code coverage to measure whether unit tests are sufficient

Common code coverage has several of the following:

Statement overlay (Statement Coverage): This is the most common and most common way of overwriting, which is to measure whether every executable statement in the measured code is executed.

Decision Overlay (Desicion Coverage): It measures whether every branch of a decision in a program is tested.

Conditional override (Condition Coverage): It measures whether the result of each subexpression in the decision is true and false is tested.

Path Coverage: It measures whether every branch of a function is executed.

The top three coverage you can view the 3rd article in the following quote, no more here. Let's look at the path overlay through an example. For example, there are two decision branches in the following test code

int foo (int a, int b)
{
    int nreturn = 0;
    if (a <)
    {//branch one
        nreturn+= 1;
    }
    if (b <)
    {//Branch two
        nreturn+=
    }
    return nreturn;
}

Let's take a closer look at the logic, the results of Nreturn a total of 4 possible, we design the test case by Path overlay method:

Perfect. But the actual code is often more complex than the above example, if there are 5 if-else in the code, then the path-covered method requires at least 25 = 32 test Cases. It's going to be crazy.

No need to pursue code coverage, really to cover the logic

Simple pursuit of code-structure coverage can easily lead to a large number of meaningless test cases or inability to overwrite critical business logic. Let's look at the first paragraph explained above.

One of the important reasons we write unit tests is to prevent ourselves from making low-level mistakes. We cannot regard the people who write the implementation code as our enemies, but we must measure all the circumstances to prevent them from deliberately leaving hidden traps. No amount of testing can be written to cover the whole situation, so just make yourself feel safe. How can you make yourself feel safe? This is no standard answer, can only be written more after the test slowly experience.

What makes you feel safe? Overwrite logic, not code. From the user's point of view, the need to care about the software implementation logic, rather than coverage. As in the following example:

public class Userbusiness {public string CreateUser (user user) {string result = Succes
   
            S "; if (string. IsNullOrEmpty (user.
            Username)) {result = ' usename is null or empty '; else if (string. IsNullOrEmpty (user.
            Password)) {result = ' Password is null or empty '; else if (user. Password!= user.
            ConfirmPassword) {result = "password isn't equal to ConfirmPassword"; else if (string. IsNullOrEmpty (user.
            Creator)) {result = ' Creator is null or empty '; else if (user.
            CreateDate = = new DateTime () {result = ' createdate must be assigned value '; else if (string. IsNullOrEmpty (user.
            Creatorip)) {result = ' Creatorip is null or empty ';
   
         }   If (Result!= "Success") {return result; } user. Username = user.
            Username.trim (); User. Password = bitconverter.tostring (MD5. Create (). ComputeHash (Encoding.UTF8.GetBytes) (user.
   
            Password)));
            Userdataaccess dataaccess = new userdataaccess ();
   
            Dataaccess.createuser (user);
        return result; }
    }

More Wonderful content: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/