The technical practice of Scrum Agile software development--test-driven development TDD

Repeating the boring definition

Test-driven development, English full name Test-driven development, abbreviated as TDD, is a new development method that differs from the traditional software development process. It requires that you write the test code before you write the code for a feature, and then write only the function code that passes the test to drive the entire development through testing. This helps to write concise and high-quality code, and accelerates the development process. (Source Baidu Encyclopedia)

The basic process of repetitive boring process test-driven development is as follows:

1. Quickly add a test (editor's note: not fast)
2. Run all the tests (sometimes just one or a few) and discover that the new tests are not going to pass
3. Make some minor changes and get the test program running as quickly as possible, so you can use some unreasonable methods in the program
4. Run all the tests and all through
5. Refactor code to eliminate repetitive design and optimize design structure

(Source Baidu Encyclopedia) but the process from Wikipedia

The explanation is slightly different, but very important.

1.ADD a testin test-driven development, each new feature begins with writing a test. To write a test, the developer must clearly understand the feature ' s specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, a nd can write the test in whatever testing framework is appropriate to the software environment. It could is a modified version of an existing test.  This was a differentiating feature of Test-driven development versus writing unit tests after the code is written:it makes The developer focus on the requirements before writing the code, a subtle but important difference.2.run all tests and SE E If the new one failsthis validates that the test harness are working correctly, that's the new test does not mistakenly pas s without requiring any new code, and then the required feature does not already exist. This step also tests the test itself with the negative:it rules out of the possibility that THe new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This step increases the developer's confidence the unit test is testing the correct constraint, and passes Tended cases.3.write Some codethe next step is to Write some code, causes the test to pass. The new code written at the "This stage" is "Not perfect" and "may", for example, pass the test on an inelegant. That is acceptable because it'll be improved and honed in Step 5.At this point, the only purpose of the written code is to pass the test; No further (and therefore untested) functionality should is predicted nor ' allowed for ' in any stage.4. Run Testsif All test cases now pass, the programmer can is confident, the new code meets the test requirements, and do Es not break or degrade any existing features. If They does not, the new code must is adjusted until they do.5. Refactor codethe growing code base must be cleaned up regularly during Test-driven DeveloPment. New code can is moved from where it is convenient for passing a test to where it is more logically belongs. Duplication must be removed. Object, class, module, variable and method names should clearly represent their current purpose and use, as extra function Ality is added. As features is added, method bodies can get longer and other objects larger. They benefit from being split and their parts carefully named to improve readability and maintainability, which'll be in Creasingly valuable later in the software lifecycle. Inheritance hierarchies May is rearranged to being more logical and helpful, and perhaps to benefit from recognised design PA Tterns. There is specific and general guidelines for refactoring and for creating clean code. [6] [7] by continually re-running the test cases throughout each refactoring phase, the developer can is confident that proces S is not altering any existing functionality. The concept of removing duplication is a important aspect of any software design.  In this case, however, it also applies to the removal of any duplication between the test code and the production code-for Example magic numbers or strings repeated in both to make the test pass in Step 3.RepeatStarting with another new test, T He cycle is then repeated to push forward the functionality. The size of the steps should always being is small, with as few as 1 to ten edits between each test run.  If new code does not rapidly satisfy a new test, or other tests fail unexpectedly, the programmer should undo or revert in preference to excessive debugging. Continuous integration helps by providing revertible checkpoints.  When using the external libraries It is important do increments that's so small as to be effectively merely testing The library itself,[4] unless there is some reason to believe that the library is buggy or was not sufficiently feature-co Mplete to serve all the needs of the software under development.

Why Test-driven development (TDD) is priceless

It ensures that all code in the system can be tested. If you have to write down all the code to cope with a failed test, then even if we do nothing, we can at least use TDD to achieve 100% code coverage.

Against "We are developing a very complex system, and I need to do some architectural work beforehand." ”

As a micro-level practice, TDD has never said that it cannot be combined effectively with a small amount of upfront architecture considerations.

"Design: Intentional and emergent"

The question is, if possible, what level of architectural considerations need to be taken in advance to strike a balance of consciousness.

"It always takes more time to write tests first, and I don't have that much time to waste. ”

Data show that TDD spends 15% more time (George and Williams 2003) than TDD. However, the data

It also shows that TDD leads to fewer flaws. Microsoft's two research shows that because of TDD, the number of defects found has dropped

24% and 38% (George and Williams 2003). It's true that TDD takes more time at the beginning,

However, by reducing the time for defect modification and maintenance, these times can be earned back.

I-a former TDD skeptic "spends 15% more time doing TDD than not doing TDD"

In the early stages, I studied TDD and tried to apply TDD to the actual product development process, and found that the actual time spent was much more than 15%.

Because there are many factors that affect the index:

• The process of TDD is familiar
• Learn how to write the right test code
• Learn how to do refactoring
• Learn how to introduce the right test framework under a specific technology stack

In my opinion, it depends on the maturity of the engineers who first tried TDD and the ability to acquire technology. Programmers who first come into contact with this concept may have to pay 100% more time than the original,

For programmers in the context of a mature TDD system, the time of all test cases for TDD is probably in the range of 10%-40%, and the specific values still depend on individual maturity.

And the nature of the project itself. However, the time we add is not just the time to build all of the test cases in TDD, but the test cases that are generated by maintaining TDD are also the time costs that the team pays.

"Due to the use of TDD, the number of defects found decreased by 24% and 38%"

The author has studied Microsoft's two parts for TDD research paper, its own experimental design is flawed, can not fully prove that the number of defects decreased, but only the empirical value, environmental factors also on the results have

Very big impact. However, as programmers grow in maturity, TDD is able to help programmers find more problems before they are delivered to QA, or to stifle defects in TDD

Ring process.

Anyway

Typically, the project itself is developed much less than its long-term operational use time, and changes in demand as the business grows, as programmers become more adept at using TDD

and team agility maturity, which can be earned by reducing the time of defect modification and maintenance.

The technical practice of Scrum Agile software development--test-driven development TDD