1. Explain TDD in detail
1.1 , TDD concept: Test Drived Develop
Test-driven development is a core practice and technique in agile development , as well as a methodology . The principle of TDD is to write unit test case code before developing functional code, and the test code decides what product code to write first. Although TDD is the core practice of agile methods, it is not only applicable to XP , but also applicable to other development methods and processes
The basic idea of TDD is to promote the entire development through testing , but test-driven development is not just a simple test work, but a quantification of requirements analysis, design, and quality control.
The important purpose of TDD is not just to test the software, the test work to ensure the quality of the code is only part of it, but also to help customers and programmers remove ambiguous requirements during the development process . TDD first considers usage requirements (objects, interfaces, functions, procedures, etc.)
1.2 Advantages and disadvantages of test-driven development
Advantages of TDD: Test Driven Development:
Any development node can come up with a product that can be used, contains a small amount of bugs , and has certain functions that can be released.
TDD : Disadvantages of Test Driven Development:
Disadvantage: Increased code effort. The test code is almost twice as large as the system code or more, but at the same time saves time in program debugging and in finding bugs.
TDD=TFD+Refactoring first test development plus refactoring
TDD: Test First Development
1.3 , TDD principle
1. Independent testing: The tests of different codes should be independent of each other. One class corresponds to one test class (for C code or C++ global functions, one file corresponds to one test file), and one function corresponds to one test function. A use case cannot use result data from other use cases, and the result cannot depend on the order of execution of the cases. A role development process includes a variety of tasks, (writing test code, writing product code, code refactoring, etc. When doing different tasks, you should focus on what you are currently doing, without considering other things, such as testing when testing )
2. Test list: There are many function points in the code. It is impossible that all requirements are very clear, but new requirements appear one after another. When you want to add functions at any stage of the process, you should put the relevant functions Points are added to the test list to avoid omissions while continuing to change the stage of work.
3. Test-driven: and the use of tests to drive development is the core of TDD . To implement a certain function, to write a certain class or a certain function, you should first write the test code, clarify how to use this class and this function, how to test it, and then design and code it.
4. Write the assertion first: When writing the test code, you should first write the assertion statement to judge the function of the code, and then write the necessary auxiliary statement.
The function should be relatively simple, each class, each function, only do its own thing, not mixed with nature and function.
6. Timely refactoring: For code with unreasonable structure, duplication, etc., refactoring should be carried out in time after passing the test.
7. Take small steps: Software development is a very complex job, and taking small steps is a good way to reduce complexity.
1.4 , TDD summary
Test-driven development: It can not only test the performance of the framework, but also test the rationality of the business, and also test the problems of the code. Although the development time will be delayed, it can improve customer satisfaction, and the system is relatively stable after going online.
The output of a software needs to have a detailed design: from the initial bidding, to project approval, to design, development, and delivery, any link is indispensable.
Example description:
A company won such a project after bidding, and built a bridge between two mountains. The product manager gave the company's designer (architect) a detailed analysis of the business and handed it over to the company's designer (architect). Usability and architecture design: The output is as follows:
The architects designed several piers with heavy strength, deck width, height, and shape. . . Wait.
In this way, the overall architecture appears, and senior engineers make small designs according to the architect's architecture, such as what kind of materials are used, how to make bridge-to-bridge associations, etc. (In terms of development, it is what interface to use, how to formulate the interface, How to ensure security) The rest will be handed over to intermediate engineers, and will be tested after development.
The simple description above is the production process of general products, but the general process is obviously not enough to do such a special project. For example, how to know whether the framework is safe or not, the current persuasion is generally reflected in the numbers and specific persuasion. The case is above, but if there is no case, we need to test the framework. Before the actual construction, the test after the framework is designed can be understood as a TDD test. At this time, the TDD is obvious . Biased towards architectural design. Going to a smaller aspect, for example, when testing an interface, it is actually designing an interface. TDD tends to design rather than testing as many people think.
An example using TDD test driver:
Business scenario: When a user places an order, the order type is "ordinary order, bulk order, personal order" to determine whether the user has the authority to place such an order.
If we design it based on this business, we will definitely have no problem:
database creation script
CREATE TABLE OederTable -- order table ( ID INT PRIMARY KEY IDENTITY (1,1), -- ID OredrNo varchar( 100 ), -- order number OrderTypeNo varchar( 100 ), -- order type number CreateBy varchar( 200 )-- creator ) CREATE TABLE UserRights -- user rights table ( OrderTypeNo varchar( 100 ),-- order type number UserID INT -- User ID ) CREATE TABLE UserTable -- user table ( ID INT PRIMARY KEY IDENTITY (1,1), --ID UserName varchar( 100 ), -- username UserPwd varchar( 200 ) -- user password ) CREATE TABLE TypeTable -- order type table ( OrderTypeNo varchar( 100 ),-- order type number OrderTypeName varchar( 100 )-- order type name )
Data input
The code to implement the test business process is as follows:
Four entity classes and one order operation class are mapped in the code.
The specific code of the order operation class is as follows (there is no specific implementation in the code, mainly based on perception ( ~o~ ))
// Test code public void TestMethod1() { OrderOperation OrderOperation = new OrderOperation(); OederTable Oeder = new OederTable(); Oeder.OredrNo = "100"; Oeder.OrderTypeNo = " 1 " ; // Ordinary order permission Oeder.CreateBy = " admin " ; // 1. Verify whether the user exists // 2. Verify whether the user has the authority to place orders // 3. Save storage / * ************ Assuming that the user table is empty, we have already queried through the username and password and the user exists ************ */ UserTable user = new UserTable( ); if (user != null ) { // Check whether the authority has the authority to place ordinary orders through UserID Oeder.OrderTypeNo = "1"; Ordinary order authority UserRights Rights = new UserRights(); if (Rights != null ) { // Add storage OrderOperation.add(Oeder); } } }
In fact, no matter what method is used, as long as the result conforms to the description, HARD Code is also a good method. We should focus on the correctness of the business process now, and it does not matter where the data comes from.
If the addition is successful, it is best to have a return value that reflects the correctness of the business, such as returning "OK" after the addition is successful
The above description is partly taken from the Internet: