How to start TDD

TDD has been proven to be a basic practice that can improve the quality of software.ProgramPersonnel, but it is difficult to practice with a try. There are a variety of factors, such as the environment, such as programming habits, such as not writing test cases. TDD is a very practical task. Like Oo, it requires a lot of practice to gain experience. Therefore, if you can develop the habit of writing and testing at ordinary times, you can perform exercises from simple to complex points 1.1, then you can gradually master TDD. It is recommended that beginners consider writing first.CodeThen write the test, wait until the test write is very skilled and then go to the first write test and then write the code.

Let's talk about how to write the code before writing the test:

I have seen that many people will use winform or console to obtain input and output when learning new technologies or writing some DEMO code. If it is a demo unrelated to the UI, we can also use the test framework to achieve the same or even better results.

For example, isun uses the console to obtain the input and output of quick sorting. In the debugging stage, the same test data may be input over and over again (for example, 1]), and then visually check whether the results are correct ([1, 2, 3, 4, 6]). The problem is that, if the code is complex and the code is correctly tested many times, the repeated input and check output become a very annoying physical labor, it is not only time-consuming, but also easy to get bored and tired. When others get this code and run it on their own machines, they also need to re-enter the data and check the output. If I get this code and perform some optimization or refactoring, I need to repeat the same input and check the output to ensure the correctness of the program. Here we can use nunit/xunit.net and other testing frameworks to automate this testing process.

Code
[Fact]
Public   Void Should_sort_array ()
{
VaR arr =   New   Int [] { 3 , 4 , 6 , 2 , 1 };
VaR expected =   New   Int [] { 1 , 2 , 3 , 4 , 6 };

VaR actual=Quicksort (ARR );
Assert. Equal (expected. length, Actual. Length );
For(IntI=0; I<Actual. length; I++)
{
Assert. Equal (expected [I], actual [I]);
}
}

 Note: The code here is only used for demonstration. It has never been run and is not guaranteed to run correctly. In addition, xunit.net seems to have an Assert Method for directly comparing arrays.

Some people say that I really want to do unit testing or TDD, but I won't write test cases. In fact, we have to test the program at any time. For example, in quicksort, your test may be to input an array and check whether the output is sorted. This is a test case. A series of inputs obtain a series of outputs. The same inputs have the same output. The input here may be some data or some actions (such as clicking some buttons on the web page), and the output may be a set of data, it may also be some actions or actions (such as clicking the button on the Web page to jump to a specific page ). Therefore, as long as you write code, you will certainly test it. As long as you test it, there will be test cases, but you have not noticed it yourself. Some may ask, what do QA/testers do if I write a test? In fact, the test cases written by developers only cover a small part. Of course, these test cases are also the most common or normal situation, therefore, you do not need to worry about your work and QA problems.

Let's take a look at the test cases for this quicksort:

Code
[Fact]
Public   Void Should_sort_empty_array ()
{
VaR arr =   New   Int [] {};
VaR expected =   New   Int [] {};

var actual = quicksort (ARR );
assertarrayequal (expected, actual);
}

[fact]
Public void should_sort_array_with_only_one_element ()
{< br> var arr = New int [] { 1 };
var expected = New int [] { 1 };

VaR actual=Quicksort (ARR );
Assertarrayequal (expected, actual );
}

[Fact]
Public   Void Should_sort_array_already_sorted ()
{
VaR arr =   New   Int [] { 1 , 2 , 3 , 4 , 5 };
VaR expected =   New   Int [] { 1 , 2 , 3 , 4 , 5 };

VaR actual=Quicksort (ARR );
Assertarrayequal (expected, actual );
}

Private   Void Assertarrayequal ( Int [] Expected, Int [] Actual)
{
Assert. Equal (expected. length, Actual. Length );
For ( Int I = 0 ; I < Actual. length; I ++ )
{
Assert. Equal (expected [I], actual [I]);
}
}

 

Now, you can modify the code with peace of mind. You do not need to input the test data, check the output, or worry that your modifications will cause program errors. For those who look at the code, they can see what kind of input will get what kind of output and how to use this method. When downloading the code for research, you do not need to input the test data yourself. If you want to change the test data, you only need to add a test.

So how do I write the test code first?

As mentioned above, testing a program is actually a test case consisting of input and output. These test cases have nothing to do with how you implement the quicksort method, because the function of quicksort is sorting, no matter how the code is implemented, it must complete the sorting function, so you only need to write according to the sorting requirements. Once you are familiar with how to write test cases, how to consider the various inputs that may be obtained by the program, from writing tests to writing tests first, it is just a process that changes your habits and will not be difficult.

Those who post code after the initiative will attach automated testing (and pay attention to the Code style and coding specifications), which is advantageous to others. Of course, you have the right to decide.