Springboot2.x tutorial básico: pruebas unitarias

Las pruebas unitarias se utilizan para probar componentes de código individuales y garantizar que el código funcione como se espera. Las pruebas unitarias las escriben y ejecutan los desarrolladores. En la mayoría de los casos, se utilizan marcos de prueba como JUnit o TestNG. Los casos de prueba generalmente se escriben a nivel de método y se ejecutan mediante automatización.
Spring Boot proporciona algunas anotaciones y herramientas para ayudar a los desarrolladores a probar sus aplicaciones.
Antes de hablar sobre las pruebas unitarias de springboot, introduzcamos brevemente los tipos de pruebas de software (desde una perspectiva de desarrollo) y cómo escribir una prueba unitaria.

Tipo de prueba de software

1. Prueba unitaria: se utiliza para probar componentes de código individuales y garantizar que el código funcione como se espera. Las pruebas unitarias las escriben y ejecutan los desarrolladores.
2. Prueba de integración: compruebe si todo el sistema funciona correctamente. Los desarrolladores también realizan pruebas de integración, pero en lugar de probar componentes individuales, su objetivo es probar entre componentes. El sistema consta de muchos componentes individuales, como código, base de datos, servidor web, etc. Las pruebas de integración pueden encontrar problemas como conexión de componentes, acceso a la red y problemas de base de datos.
3. Prueba funcional: verifique si cada característica está implementada correctamente comparando el resultado de la entrada dada con la especificación. Esta etapa generalmente la maneja el equipo de pruebas dedicado de la empresa.
4. Prueba de aceptación: La prueba de aceptación es para asegurar que el software está listo, de acuerdo con el contrato del proyecto, la declaración de asignación y el documento de aceptación acordado por ambas partes, para mostrar al comprador del software los requisitos originales del software.

Puntos de prueba unitaria

1. La granularidad de la prueba es a nivel de método.
2. El resultado del caso de prueba debe ser estable.
3. El caso de prueba debe escribir la menor lógica posible o no escribir la lógica de prueba.
4. Los casos de prueba deben tener una alta tasa de cobertura, que cubra la entrada y la salida básicas, y también deben cubrirse algunos límites.
5. Utilice afirmaciones en lugar de generar declaraciones impresas.
6. El caso de prueba unitario debe tener un buen nombre, como test_MethodName ()

Prueba unitaria de integración SpringBoot

Introducir dependencias

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-test</artifactId>
	<scope>test</scope>
</dependency>

Dependencia

1. JUnit: el estándar de facto para pruebas unitarias de aplicaciones Java.
2. Spring Test y Spring Boot Test: compatibilidad con pruebas de integración y utilidades para aplicaciones Spring Boot.
3. AssertJ: una biblioteca de afirmaciones fluida.
4. Hamcrest: una biblioteca de objetos comparadores (también conocidos como restricciones o predicados).
5. Mockito: un marco de simulación de Java.
6. JsonPath - XPath para JSON

Descripción de la anotación común

• @RunWith (SpringRunner.class)
  JUnit se ejecuta utilizando el soporte de prueba de Spring. SpringRunner es el nuevo nombre de SpringJUnit4ClassRunner. El propósito de hacerlo es simplemente hacer que el nombre parezca más simple.
• @SpringBootTest se
  usa para las pruebas de la aplicación Spring Boot. De forma predeterminada, buscará nivel por nivel de acuerdo con el nombre del paquete. Siempre encuentra el programa principal de Spring Boot. Determina si el programa principal es el programa principal por si la anotación de clase contiene @SpringBootApplication e inicia la clase durante la prueba. Crea un entorno de contexto Spring.
• @BeforeClass
  se ejecuta solo una vez para todas las pruebas y debe ser vacío estático
• @BeforeEach
  método de inicialización, ejecutado antes de que se ejecute cada método de prueba de la clase de prueba actual
• @Test
  método de prueba, donde puede probar la excepción esperada y el tiempo de espera
• @AfterEach
  libera recursos y ejecuta cada método de prueba de la clase de prueba actual
• @AfterClass
  se ejecuta solo una vez para todas las pruebas y debe ser vacío estático
• 
  Métodos de prueba ignorados por @Ignore

Afirmación de uso común

1. asertNotNull ("mensaje", A) // El juez A no está vacío
2. asertFalse ("mensaje", A) // La condición de juicio A no es verdadera
3. asertTure ("mensaje", A) // Juzgar la condición A es verdadera
4. asertEquals ("mensaje", A, B) // 判断 A.equals (B)
5. assertSame ("mensaje", A, B) // 判断 A == B

método de prueba

@RunWith(SpringRunner.class)
@SpringBootTest
public class UserRepositoryTest  {
    @Autowired
    UserRepository userRepository;
    @Test
    @Ignore
    public void testFindAll(){
        Page<UserDO> userDOS= userRepository.findAll(PageRequest.of(1,10));
        Assert.assertNotNull(userDOS.getContent());
    }
    @Test(expected = RuntimeException.class)
    public void testNullPointerException(){
        throw new RuntimeException();
    }
}

Prueba de la interfaz API

• MockMvcRequestBuilders
  construye la ruta de solicitud, los parámetros de solicitud y otra información
• andExpect
  agrega una afirmación para determinar si el resultado cumple con las expectativas
• andDo
  agrega un procesador de resultados, como la impresión en el ejemplo
• andReturn
  devuelve el MvcResult después de una verificación exitosa, que se utiliza para la verificación personalizada / procesamiento asincrónico del siguiente paso.

@RunWith(SpringRunner.class)
@SpringBootTest
@AutoConfigureMockMvc
class UserControllerTest {
    @Autowired
    MockMvc mockMvc;
    UserDO userDO;
    MultiValueMap<String,String> params;
    @BeforeEach
    public void setUp()throws Exception{
        userDO=new UserDO();
        userDO.setPasswd("123456");
        params=new LinkedMultiValueMap<>();
        params.add("name","codehome");
    }
	//测试get接口
    @Test
   public  void queryUser() throws Exception {
      String result= mockMvc.perform(MockMvcRequestBuilders.get("/user/query")
            .contentType(MediaType.APPLICATION_FORM_URLENCODED)
                .params(params)
        ).andExpect(MockMvcResultMatchers.status().is2xxSuccessful())
        .andDo(MockMvcResultHandlers.print())
                .andReturn().getResponse()
                .getContentAsString();
        Assert.assertEquals("调用成功","codehome",result);
    }
	//测试post接口
    @Test
    void addUser() throws Exception {
        mockMvc.perform(MockMvcRequestBuilders.post("/user/add")
            .contentType(MediaType.APPLICATION_JSON)
                .content(JsonUtil.toJson(userDO))
                .accept(MediaType.APPLICATION_JSON)
        ).andExpect(MockMvcResultMatchers.status().is2xxSuccessful())
                .andDo(MockMvcResultHandlers.print())
                .andExpect(MockMvcResultMatchers.jsonPath("$.data.passwd").value("123456"));
    }
	//测试cookie
    @Test
    void testCookie()throws Exception{
       String token= mockMvc.perform(MockMvcRequestBuilders.get("/user/cookie")
        .cookie(new Cookie("token","123456")))
                .andDo(MockMvcResultHandlers.print())
                .andReturn().getResponse()
                .getContentAsString();
       Assert.assertEquals("token从cookie中获取成功","123456",token);
    }
}
//测试的接口类
@RestController
@RequestMapping("/user")
public class UserController {
    @GetMapping("/query")
    public String queryUser(String name){
        return name;
    }
    @PostMapping("/add")
    public R addUser(@RequestBody UserDO userDO){
        return R.ok(userDO);
    }
    @GetMapping("/cookie")
    public String testCookie(@CookieValue("token") String token){
        return token;
    }
}

Mil millas comienzan con un solo paso. Este es el séptimo artículo de la serie de tutoriales de SpringBoot. Todos los códigos fuente del proyecto se pueden descargar en mi GitHub . **