What is test-driven development?

After several days of observation, I found that many comrades have not yet understood what is "test-driven development ": what is the purpose of the test written before development-the reason for saying "surprise" is that there are both "surprises" and "surprises ". I will explain a little about the problems I encountered in my recent university lectures.

(Discussed earlier:
Http://forum.javaeye.com/viewtopic.php? T = 19959
Http://forum.javaeye.com/viewtopic.php? T = 20035)

The name of "test-driven development" should first be clear: it corresponds to "document-driven development ". It is a development process. The test here is a design issue, not a QA issue. Before TDD is available, the "Orthodox" development process requires a design document: a high-level design describes a module "what to do", and a detailed design describes a module "how to do these things ". Software engineering courses are clear, onlySource codeThe software cannot be regarded as software because it is not understandable or maintained; SourceCodeAdd a document.ProgramComplete delivery of their work. Before doing anything, you must first know exactly what you want to do (and do not do anything); otherwise, it is crack, not a professional software development.

But such documents have several fatal defects. First, natural language descriptions are prone to ambiguity. Second, they cannot be verified automatically. Third, documents and programs cannot be synchronized. Test-driven development is designed to solve these problems. The test you wrote before writing a piece of code is not to ensure that the Code does not go wrong, butDescribe what you want to do. When you have this test, continuous integration always ensures that your code is exactly what you want to do. Test-driven development is a design method that clearly describes your design and ensures that the design and implementation are consistent.

you can find the answer to several typical questions clearly. Should unit testing be a white box? Yes. Because you are describing how to implement this module , rather than verifying its input and output correctness. Do you want to test each module in a real transaction or concurrent environment? No. Because you only describe the implementation of the current module, the correctness in the real environment is ensured by integrated testing and QA. Why should changes in the internal implementation of the module cause both test changes? Because of your ideas and design changes, you should have a document to describe this matter.