How to start TDD

TDD has proven to be a basic practice for improving software quality, but for many programmers, it's difficult to practice with the idea of trying. There are many factors in this, such as the environment, such as programming habits, such as not writing test cases and so on. TDD is a very practical thing, like Oo need a lot of practice to gain experience, so if you can develop the habit of writing tests, from simple to complex 1.1 points to practice, you can slowly grasp TDD. It is suggested that beginners can consider writing the code after writing the test, wait until the test is very skilled, and then go to the first write the test after the stage of writing code.

First of all, how to write the code and then write the test:

I've seen a lot of people using WinForm or console to get input and output when they're learning new technology or writing some demo code, and if it's a UI-independent demo, we can also use the test framework to get the same or even better results.

For example, a quick sort of Isun writes, he uses the console to get input and output, and in the debug phase it is possible to enter the same test data over and over again (for example, [3,4,2,6,1]) and then visually inspect the results ([1,2,3,4,6]). The problem with this is that if the code is complex and tested many times to do the right thing, the repetitive input and check output becomes a tiresome manual labor that takes time and makes people irritable and tired. When someone else gets the code and runs on their own machine, it also needs to re-enter the data and check the output. If I get the code and do some optimization or refactoring, I'm going to repeat the same thing and check the output to make sure the program is correct. Here we can use the Nunit/xunit.net test framework to automate this test process.

[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 (int i=0;i<actual.　　 length;i++)

{

assert.equal (expected[i],actual[i]); 

}

}

Note: The code here is demo-only, not run, not guaranteed to run correctly; another xunit.net seems to have an Assert method that compares arrays directly.

Some people say I'd like to do unit tests or TDD, but I don't write test cases. In fact, any time we write a program, we have to test their own, such as this quicksort, your test may be to input an array, and then see if the output is sorted. So this is a test case, a series of inputs that get a series of outputs, and for the same input, there is the same output. The input may be some data, or some action (such as clicking on some buttons on a Web page), the output may be a set of data, or some action or action (such as clicking on a Web page button to jump to a particular page). So as long as you can write code, you will certainly test, as long as the test, there will be a test case, but you do not realize it. Some people might ask, if I had written a test, what would the qa/tester do? In fact, the test cases written by developers only cover a very small part of it, of course these test cases are the most frequent, or the most normal situation, so there is no need to worry about your work and QA heavy problems.