Agile Testing (1) TDD concept

Signature

This series of notes will summarize the Test experience of Baidu in two years from the Tester 's point of view, documenting a complete process of acceptance testing based on the Agile process , and sharing some knowledge and experience in the testing process. And some of their own ideas. summed up their own, but also hope to benefit everyone.

Concept

Acceptance test-driven development (ATDD) and test-driven development (TDD) are two completely different concepts.

TDD is more emphasis on automation case first, and ATDD more emphasis on acceptance details, quality standards first.

Before you know ATDD, review the following TDD:

Test-driven Development (TDD)

One of the methods of extreme programming, starting from the business, to test the first way to reverse the implementation of the Code. So what is TDD?

Simply put, whenever you need to add a new feature, or modifying existing functionality, we first think about the input and output that this part of the code expects to achieve, write down the unit test case that validates the business, write the simplest implementation code to pass the test, and repeat the process until the entire function is complete.

Note: TDD is the responsibility of developers.

Typical TDD development steps:

Step 1: Analyze and identify a target test scenario

Step 2: Add a unit test to validate the input and output of the test scenario

Step 3: Run the test and get the test results that failed

Step 4: Write the simplest functional code to pass the test

Step 5: Run the test again and see that the test passes

Step 6: Code refactoring, including functional code and unit test code

Step 7: Repeat the above steps until the development is complete

Recommended best practices to follow in TDD development:

1. Simplify-keep test cases as simple as possible to validate business as the primary goal

2. Business orientation-testing every business scenario that needs to be validated, rather than testing each method of the code

3. Isolation-Each test class (TestCase) can be run independently, not dependent on any other tests; Likewise, many test classes can be executed together without interfering with each other.

4. Refactoring-developed unit testing and functional code need to be constantly refactored, improve code readability, maintainability, reduce redundant code, etc.

5. Test list-Before starting development, list all required tests, and maintain the list in development to avoid forgetting some of the necessary tests

6. Reverse engineering-in some development environments, such as eclipse, you can use the reverse engineering capabilities provided by the IDE to automatically generate the necessary classes from test code, methods, and so on

7. Note-No separate documentation is required, but a detailed description of the business scenario, input, and expected output for each test method in the test class

Benefits of TDD:

1. Improve code Quality-test first, and achieve adequate coverage to ensure that the code has been tested

2. The system is described-TDD test is a complete set of documentation for the system, all the business, the use of each method here are described. If anyone wants to get to know your system, let him see the test:

3. Self-confidence refactoring-TDD can produce a complete set of test suites, every time we refactor the code, it's convenient to execute existing tests to ensure that the new improvements do not affect the logic and behavior of the code, and that, once each defect is resolved, you can make sure that other features are not affected by executing the existing tests. No new flaws were introduced. This allows the team to be more confident to refactor the code

4. Automated regression testing-TDD-generated test suites can be combined with automated continuous process environments, partially automating regression testing, and significantly increasing the frequency of regression testing while reducing the time spent

5. Eliminate waste-TDD helps the development team avoid redundant, useless code, and avoid the unknown code that no one can read

6. Reducing debugging-programming through TDD can greatly reduce the need for code debugging and save time

7. Simplified design-under the guidance of the outline design, TDD can replace most or even all of the detailed design (Implementation class, method level design)

8. More modular-because TDD requires developers to decompose a function into smaller units that can be tested and then set to a whole. Such thinking and development patterns will produce smaller, clearer, more accountable classes, more loosely coupled components and clear interfaces

Limitations of TDD:

1. The quality of the code produced by TDD depends on the quality of the test, that is, improper, incorrect testing produces the wrong code, and the incomplete testing of the business scenario will result in incomplete code;

2. TDD is only suitable for input and output clear development projects, not for certain exploratory, output uncertain development, such as cryptography, artificial intelligence, security and other areas of research and development;

3. TDD can be difficult to implement in some environments, such as relational databases , asynchronous communications, and so on, requiring additional assistive tools.

Finally, as a new design and programming approach, implementing TDD in a project presents some new challenges for developers:

* Change of responsibilities-some developers believe that his job is to implement functionality, write code, and that testing is just a matter for testers, not within his purview. This is the wrong understanding, complete High-quality Unit testing is also the responsibility of developers!

* Change of mindset-many developers get the need and like to start writing code immediately. TDD requires testing first, and the first thing developers need to think about is not how functionality is implemented, but how to validate it and list the test scenarios that are needed. This is a big reversal of thinking.