[Recommendation] Twelve principles of extreme programming-test

Test: If a function exists, a test can verify it, and any code that may be damaged must have a corresponding test.

In the past, when the hardware environment was limited, the programming efficiency was very high and the memory usage had to be carefully calculated. Soon, the hardware environment has been greatly improved, and development tools have become more and more "Dummies", so programmers no longer have to worry about it. However, gradually, the programmer's conciseness awareness has become increasingly weak, memory leakage is becoming more and more serious.

I was very impressed by the fact that I have heard of a colleague who once told me that the software package department once handed over the program after the test, as a result, the external party accepts the test cases one by one. As a result, when an operation is repeated for nearly 500 times, the program crashes. When the foreign party gave this information to Chinese personnel, their first response was "these people are crazy. Who will repeat this operation so many times !", This is because they did this once during the test. If a result is correct, the test passes.

In my understanding, the test principle should be the most important principle in Agile development. For agile development, changes are welcome, which means frequent changes. If this frequent modification is not guaranteed by tests, the final result will only be a pile of garbage with hundreds of errors and hidden risks. This is also an important reason why many agile development practices fail: in practice, the importance of testing is ignored, or, the agile development practices will be in a rush if there is no ability to perform standard-compliant testing.

When talking with many people about agile development and extreme programming, we are most interested and envious of the features of team-end programming, working for 40 hours, and reducing documents, it seems that these features of agile development attract them to focus on Agile development. However, we ignore the principles that really require us to think about testing and restructuring. When talking about testing problems, they will say that we are doing this now! However, have we seriously considered whether the tests we are doing are comprehensive and whether our understanding of the purpose, significance, and methods of the tests is in place?

In extreme programming, seven types of tests are summarized. Let's take a look at what we can do in our current tests? :

(1) Automated regression test)

Run the automated test code to verify that the current modification does not break the existing functions.

(2) Unit test)

Verify that the code at the unit level works properly.

(3) Public API test)

Verify that APIs called by third-party developers can work properly and be documented.

(4) Private API test)

Verify that the APIs used internally work properly.

(5) Command-line test)

Verify that the command entered in the command line works properly.

(6) User interface test)

Verify that the interface layer functions normally.

(7) Dog-food test)

Here we use an interesting name "Dog-food test", and try your "Dog food" first! Use self-developed products within the enterprise to ensure that the functions are correct and meet the usage requirements.

 

Developers will have a long-term idea: testing is what testers do! Although we require self-testing before submitting the test, what I see is only a self-testing report. Do we have test cases during self-testing? Is there any test code? Have these test codes been well preserved so that they can be reused for regression testing when a program is modified in the future?

In the previous Software Development Team, we required that all data layers (java programs) should have unit test code to test the output XML format data, and submit the XML format data as an interface to the interface layer (javaScript, HTML) to test the interface function, but also to the middle business layer (java program) for unit test to verify the output input of business functions. All these are test cases and code written by developers using the Junit framework, and all of them plan the directory structure like the source program and implement version control as part of the source program structure. These methods ensure that the unit test code can effectively ensure functional verification after the software is changed when personnel changes and programs need to be modified.

In fact, I have always felt that no matter software or hardware development, testers should have rich development experience and have a deeper level of thinking than developers. In the case of agile development practices, the difference between developers and testers is nothing more than the difference between coding and testing code. In terms of coding difficulty, there is no difference between the two, even to the extent of thinking, writing test code requires more and more depth.

It can be seen that agile development has such a high requirement on testing, which puts forward a high requirement for all teams who want to conduct agile development practices: can we bring tests to such a high level? Are we capable of such high testers? Can we stick to the principle that no matter how tight the task is, we cannot cut down the test? All these problems are, in essence, a challenge to long-standing opinions and habits. Therefore, agile development is not so much a development method as a development concept. What it needs is actually a change in our concepts!