Por fin luego de mucho trabajar ya hallamos el resultado de este rompecabezas que agunos lectores de nuestro sitio web tienen. Si tienes algo más que aportar puedes compartir tu comentario.
Solución:
¿Por qué necesita Spring para hacer pruebas unitarias? Solo puede usar Mockito para hacerlo sin la necesidad de iniciar el contexto de primavera. Esto se explica y analiza en detalle aquí: https://reflectoring.io/unit-testing-spring-boot/
¡También es muy confuso para mí cuando se trata de usar @MockBean! ¿Eso se considera una unidad o una prueba de integración? En mi opinión, incluso estamos usando un frijol simulado, pero todavía estamos ejecutando dentro del contexto de primavera y para mí esta es una prueba de integración (ya que una prueba unitaria no necesita ningún contexto de primavera para ejecutarse). El mismo sitio que mencionó Brandon considera @MockBean una prueba de integración https://www.baeldung.com/java-spring-mockito-mock-mockbean.
Imagen del sitio de arriba
De la respuesta de Brandon: “Las pruebas de integración no deben contener ninguna simulación y ambos tipos de pruebas deben ejecutarse por separado”.
¿Qué sucede si desea probar una API desde el controlador hasta la base de datos, pero desea excluir otros sistemas (como kafka o microservicios externos)? ¿Cómo lograrías esto? Definitivamente necesitas @MockBean. Esta es una prueba de integración incluso si tiene frijoles simulados.
En resumen (según mi experiencia y después de buscar y leer mucha información contradictoria durante días). Aquí está mi opinión:
- Yo diría que evite usar Spring para pruebas unitarias tanto como sea posible y simplemente use Mockito u otro marco que no necesite contexto Spring. Por ejemplo, al escribir una prueba para una clase de servicio para probar alguna lógica de cálculo, no necesitamos el contexto de primavera y esta es una prueba de unidad PURA.
- Todavía podemos escribir pruebas unitarias PURAS para clases de controlador. Podemos hacer eso llamando a los métodos en el controlador, luego afirmar que estos métodos hicieron lo que se esperaba (por ejemplo, llamando a los métodos subyacentes correctos con los parámetros correctos, etc.). Básicamente de la misma manera cuando se escribe una prueba unitaria para una clase de servicio. (¿Tal vez estos no sean necesarios si ya se cubrirán en los siguientes tipos de pruebas?)
- Todavía podemos escribir pruebas unitarias puras para apis sin ningún contexto de primavera. Esto descrito aquí. Probé y funcionó para mí. Pegaré el código al final del post.
- Cuando se ejecuta una prueba en el contexto de primavera, se considera una prueba de integración incluso si está utilizando @MockBean. Un ejemplo de esto: si queremos probar una API desde el controlador hasta la base de datos, pero queremos excluir otros sistemas (como kafka, correo electrónico u otros microservicios externos). ¿Cómo lograríamos esto? Definitivamente necesitamos @MockBean. Esta es una prueba de integración a pesar de que usa algunos beans simulados.
-
Creo que la parte más confusa es cuando solo se prueba la capa API.usar spring como UserControllerTest en la pregunta hace (Me refiero a llamar a la API y asegurarse de que devuelva el código de estado y el formato de respuesta correctos). ¿Eso se considera una prueba unitaria o una prueba de integración? No es una unidad, ya que las pruebas unitarias no necesitan un contexto de primavera para ejecutarse. En realidad, es algo intermedio entre las pruebas unitarias y de integración. Esta fuente explica muy bien este concepto https://blog.marcnuri.com/mockmvc-spring-mvc-framework/ (más específicamente, la configuración independiente de MockMvc) Así que creo que se remonta al equipo donde colocar estas pruebas (en la carpeta de prueba de unidad, en la carpeta de prueba de integración, en una carpeta separada?) También se necesita una buena convención de nomenclatura para evitar confusiones con pruebas de unidad puras o pruebas de integración puras para la misma clase. Por lo que vi, la mayoría de los equipos consideran esas pruebas unitarias, ¡pero no estoy seguro de si esa es la mejor práctica!
//unit test to call an api using MockMvc and mockito only @RunWith(MockitoJUnitRunner.class) public class UserControllerTest private MockMvc mockMvc; @Mock UserService userService; @InjectMocks UserController controllerUnderTest; @Before public void setup() MockitoAnnotations.initMocks(this); mockMvc = MockMvcBuilders.standaloneSetup(controllerUnderTest).build(); @Test public void testGetUser() throws Exception //given: when(userService.getUser(.......)).thenReturn(....); //when: String url = "http://localhost:8081/api/ ....your url"; //then: this.mockMvc.perform(get(url)).andDo(print()).andExpect(status().isOk());
Espero que ayude y avíseme si hay alguna opinión mejor porque luché mucho con eso 🙂
Las pruebas unitarias se ejecutan de forma aislada, mientras que las pruebas de integración inician el contexto web de Spring antes de que comience la ejecución.
PRUEBAS DE UNIDAD
La ejecución aislada a veces requerirá que simule sus dependencias en función de la clase que está probando. Al hacer esto, se permite probar casos de prueba muy específicos de un extremo a otro sin tener que preocuparse por la sobrecarga del servicio o las capas de dominio. Por lo tanto, usar Mockito o, más específicamente, el método Mockito.mock() que se burla de las clases de objetos y NO reemplaza ningún objeto en el contexto web, como @MockBean.
PRUEBAS DE INTEGRACIÓN
Mientras que las pruebas de integración se centran en integrar diferentes capas de la aplicación, como la base de datos. Con respecto a las bases de datos, la mayoría de las personas utilizan una base de datos en memoria como H2 para probar sus capas/repositorios de dominio. Las pruebas de integración NO DEBEN contener ninguna simulación y ambos tipos de pruebas deben ejecutarse por separado. Esto no quiere decir que las pruebas de integración no puedan contener simulaciones, pero no es común ya que ya tiene pruebas unitarias aisladas que prueban las diversas capas de su aplicación que contienen dependencias simuladas.
PRUEBAS E2E
Si está probando su aplicación de principio a fin, es mejor que no se burle de nada más que de sus datos, con una limpieza adecuada. Los marcos de prueba como Cucumber son excelentes para las pruebas de extremo a extremo. ¿Por qué te burlarías de diferentes capas? ¡Ya tienes pruebas unitarias para ese tipo de prueba!
Recursos: https://www.baeldung.com/spring-boot-testing y https://www.baeldung.com/java-spring-mockito-mock-mockbean
Si tienes algún dificultad o capacidad de aclarar nuestro división eres capaz de añadir una explicación y con placer lo interpretaremos.