TDD Development sentiment

As the company intends to develop TDD form, it is ready to be put into the arms of TDD in subsequent projects.

In the process of looking for some reference books, ran into the "test-driven development of the art" This book, the code for the Java faction, but the content of the book is easy to understand, the author of the book belongs to the real-world writers, so a few chapters directly on specific examples, and then through testing, development, reconstruction, testing, development, reconstruction Process to demonstrate how to practice TDD.

In the process of reading, I gradually have a new understanding of TDD, has now seen the third chapter, through the guidance of the previous author, I understand the TDD is this:

TDD, test-driven development, is a software development process of practice, is a concept, rather than the implementation of the tool. It requires software developers in the process of developing software, in accordance with testing, development, reconstruction, testing, development, reconstruction .... Of the process, to a bit of building software.

Mapping to my previous design work, I did realize the convenience of TDD:

Previous development: Waterfall Development, write the function code, encountered the compilation error place, directly debug the project, and then let it compile through, there is no real to detect whether the function is normal; even if there is time to write a test case, it is only for the core business logic to cover, no refactoring involved, The process of testing, so sometimes in the development completed, found that the problem is quite a lot.

TDD Development: Write the failed test first, then modify it to pass the test, then implement the function code, then test, then refactor, then test, then develop, then refactor ... Anyway is to ensure that each writing function points are available, are passed the test. After the formal delivery of the software, all of these tests can be used as a system after the problem of the detection basis, can be easily located to the point of error. If the project is very large, it is very valuable to be able to quickly locate the error point. (In the past when Citi made the software, there is a huge project, the core logic is written in C + +, the presentation layer is written in C #, the bonding layer is written in the CLR C + +, the project is very many threads, sometimes when the performance layer error, need to locate the error, from C # debugging to the CLR C + +, And then to native C + + debugging, the process is miserable, most importantly, the entire project compiled once, takes four or five hours ... Through this period of time, just know the importance of this mechanism of TDD, the author's feelings, in my heart has Obsession Yan. Salute. ）

But TDD is not everything, TDD can help us write well-run software , but we still have to find a way to ensure that the delivery of the function to meet the needs of customers. Here we are referring to the term "acceptance test driven development", and we look and go.

TDD Development sentiment