Read notes on xunit test mode-test code Reconstruction

Because the product testing project is extremely difficult to use, it is slow, big, messy ,...... The key is that no version manager is willing to spend manpower on testing code. When I saw this book, I thought I could find the truth and go to the company library to study it. Quick browsing is far from ideal. Although the cover shows that the book has won the U.S. Productivity Award, it is not a grade compared with agile software development principles, models, and practices, we can't judge a book by its cover. Most of the content is familiar, so although this book is very thick, it is not surprising. I am not satisfied with the Chinese translation. It is too blunt. Many key terms are not the first-line idioms (such as "fresh jigs"). It is no longer difficult to read English directly.
Xunit. Test. patterns. refactoring. Test. Code. may.2007

1. Misuse of setup

Xunit provides the setup method. Some beginners don't know such a good thing, and some know it, but they don't use it if they don't reasonably group the test method. The effect is not good.

This book makes an analogy: "If you have a hammer, everything looks like a nail !"

In addition to setup, mock is similar. Mock is a good thing, but if you see a test case using 25 mocker (...), What does it feel like? This is a real example that I have seen in our product test code. After five seconds of thinking, I directly dropped the test case.

Another example worth mentioning is the inheritance in the object-oriented model. Beginners often want to reuse everything.

It can be said that "teenagers don't know what it is like, and they are eager to talk about new words ."

 

2. How to reduce test code replication?

We often see Test Cases with similar segments, which are apparently copy-paste, especially in the result verification lines. There are several ways to eliminate duplicates:

Use expected objects;

Custom assertions;

Encapsulation verification method;

Parameterization and data-driven;

 

3. How do I compile a testing code with obvious intentions?

Write the test code before writing the product code;

Write assertions before writing test codes;

The identifier name should clearly reflect the intent;

 

4. It is recommended that one of the reasons for each test is to facilitate positioning.

5. How to design test cases?

Three methods:

(1)
Each class (module) has a test case class;

(2)
One test case class for each feature;

(The advantage is that it is easy to understand business scenarios and use proper names );

(3)
One test case class for each precondition;

(This facilitates putting preconditions in the setup method, but does not abuse setup .)

 

The above is not the best, only the most suitable.

"The best practice is the best practice that is best suited to a specific environment ."

 

6. Bad taste of code

Taste 1: Long test

It is difficult to understand and maintain, and cannot act as a document.

Typical causes of long testing:

(1)
Responsibilities are not uniform. There are too many functions to verify.

(2)
There are mysterious visitors. The causal relationship between preconditions and verification logic is not intuitive and obvious, and relies on mysterious external resources (such as files ).

(3)
Too many preconditions.

(4)
Irrelevant information (variables and values) is placed at the level of interest to the reader );

(5)
Hard-coded value;

(6)
Indirect test;

 

Taste 2: hard-to-test code

Such as GUI, multi-task, and message.

For highly coupled code, mock is recommended.

We recommend that you encapsulate the task body code to test the encapsulation.

 

Taste 3: Test code Replication

Taste 4: Test logic in the product

7. Bad Behaviors

 

Taste 1: accumulating multiple assertions in a test method reduces the number of Use Cases

Taste 2: unstable testing, sometimes successful, sometimes failed

The reason may be the coupling between tests, the sharing conditions, or the migration of their own status.

Taste 3: manual debugging, such as one-step tracking, view memory

Taste 4: slow

Cause: compilation is slow, testing classification, or dependency on header files is unreasonable, resulting in unnecessary Association, latency, and big data copying.

The impact significantly increases costs and reduces team productivity.

 

8. Bad project taste

Taste 1: developers do not dt

Time-consuming: No need to consider test refactoring;

Insufficient skills: lack of test design and TDD experience;

Taste 2: maintenance costs

The increase in combat capability and coverage rate reduces the productivity of the team and consumes a lot of energy.

Taste 3: Use Cases

Why is it difficult to write use cases first in the early stage of the project?

Taste 4: Use # If 0 to inject a large number of cases that are difficult to maintain

Most of these cases that are difficult to maintain are supplemented.

Taste 4: defects easily discovered by llT after testing