Writing Clean Tests

1、We Should Not Use Inheritance In Our Tests 测试代码中不要使用继承。

2、we must configure our test cases in a clean and simple way.

We can improve the readability of our configuration by configuring all test cases in the test class. This means that we have to:

• Add the required annotations (such as @RunWith) to the test class.
• Add the setup and teardown methods to the test class.

If we modify our example test class by following these rules, its source code looks as follows:

3、Divide and ConquerDivide and Conquer

import org.junit.Before;
import org.junit.runner.RunWith;
import org.mockito.Mockito;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.web.WebAppConfiguration;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.setup.MockMvcBuilders;
import org.springframework.web.context.WebApplicationContext;
 
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = {WebUnitTestContext.class})
@WebAppConfiguration
public class TodoControllerTest {
 
    private MockMvc mockMvc;
     
    @Autowired
    private TodoService serviceMock;
 
    @Autowired
    private WebApplicationContext webAppContext;
 
    @Before
    public void setUp() {
        Mockito.reset(serviceMock);
        mockMvc = MockMvcBuilders.webAppContextSetup(webAppContext).build();
    }
 
    //Add test methods here
}

In my opinion, the new configuration of our test cases looks a lot simpler and cleaner than the old configuration which was divided into TodoControllerTest and AbstractControllerTest classes.

Unfortunately, nothing is free.

4、 Naming Matters 

     why we should pay attention to naming and describes a few useful naming conventions which will help us to write clean tests.

5、Beware of Magic

• We must give good names to constants and constants classes. If we don’t do that, we aren’t leveraging the full potential of these techniques.
• We shouldn’t introduce new constants without figuring out what we want to achieve with that constant. The reality is often a lot more complex than the examples of this blog post. If we write code on autopilot, the odds are that we will miss the best solution to the problem at hand.

6、it is a bad idea to create objects in the test method by using the new keyword

• It is a bad idea to create the required objects in the test method by using the new keyword because it makes our tests messy and hard to read.
• If we have to set only a handful of property values and our test data doesn’t have a lot of variation, we should create the required object by using a factory method.
• If we have to set a lot of property values and / or our test data has a lot of variation, we should create the required object by using a test data builder.

7、Replace Assertions with a Domain-Specific Language

• Following the data centric approach causes unnecessary confusion and friction between the developers and the domain experts.
• Creating a domain-specific language for our assertions makes our tests less brittle because the actual assertion logic is moved to custom assertion classes.
• If we write assertions by using a domain-specific language, we transform our tests into executable specifications which are easy to understand and speak the language of the domain experts.

8、Divide and Conquer

• We learned that we can identify the logical concepts covered by a single unit test by identifying the situations when that test will fail.
• We learned that writing unit tests which test only one logical concept helps us to write transform our test cases into executable specifications, which identity the requirements of the tested method / component.

9、Mock external dependencies (and state)

10、Small Is Beautiful

具体介绍：http://www.petrikainulainen.net/writing-clean-tests/9、