Saltar al contenido

Cómo probar la clase principal de la aplicación Spring-boot

Luego de investigar con especialistas en la materia, programadores de deferentes áreas y profesores dimos con la solución a la pregunta y la plasmamos en esta publicación.

Solución:

Todas estas respuestas parecen exageradas.
No agrega pruebas para hacer feliz a una herramienta métrica.
Cargando un contexto Spring de la aplicación requiere tiempo. No lo agregue en cada compilación de desarrollador solo para obtener alrededor del 0,1 % de cobertura en su aplicación.
Aquí no cubre solo 1 declaración de 1 método público. No representa nada en términos de cobertura en una aplicación donde generalmente se escriben miles de sentencias.

Primera solución: cree su clase de aplicación Spring Boot sin un bean declarado en su interior. Si los tiene, muévalos en una clase de configuración (para que aún estén cubiertos por prueba unitaria). Y luego ignore su clase de aplicación Spring Boot en la configuración de cobertura de prueba.

Segunda solución: si realmente necesita cubrir el main() invocación (por razones organizativas, por ejemplo), cree una prueba para ella pero una prueba de integración (ejecutada por una herramienta de integración continua y no en cada compilación de desarrollador) y documente claramente el propósito de la clase de prueba:

import org.junit.Test;

// Test class added ONLY to cover main() invocation not covered by application tests.
public class MyApplicationIT 
   @Test
   public void main() 
      MyApplication.main(new String[] );
   

puedes hacer algo como esto

@Test
public void applicationContextLoaded() 


@Test
public void applicationContextTest() 
    mainApp.main(new String[] );

Tenía el mismo objetivo (tener una prueba que ejecuta el método main()) y me di cuenta de que simplemente agregando un método de prueba como @fg78nc dicho “iniciará” la aplicación dos veces: una vez por el marco de prueba de arranque de primavera, una vez a través del invocación explícita de mainApp.main(new String[] )que no me parece elegante.

Terminé escribiendo dos clases de prueba: una con @SpringBootTest anotación y el método de prueba vacío applicationContextLoaded()otra sin @SpringBootTest (solamente RunWith(SpringRunner.class)) que llama al método principal.

Prueba de aplicación SpringBoot

package example;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.junit4.SpringRunner;
import org.springframework.boot.test.context.SpringBootTest;

@RunWith(SpringRunner.class)
@SpringBootTest
public class SpringBootApplicationTest 

  @Test
  public void contextLoads() 
  

Prueba de inicio de aplicación

package example;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.junit4.SpringRunner;

@RunWith(SpringRunner.class)
public class ApplicationStartTest 
  @Test
  public void applicationStarts() 
    ExampleApplication.main(new String[] );
  

En general, la aplicación todavía se inicia dos veces, pero ahora hay dos clases de prueba. Por supuesto, con solo estos dos métodos de prueba, parece excesivo, pero generalmente se agregarán más pruebas a la clase. SpringBootApplicationTest aprovechando @SpringBootTest configuración.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *