java - example - test controller spring boot

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

Question

Tengo una aplicación spring-boot donde mi clase de inicio @SpringBootApplication parece una estándar. Así que creé muchas pruebas para todas mis funcionalidades y envié el resumen a sonarqube para ver mi cobertura.

Para mi clase inicial, Sonarqube me dice que solo tengo un 60% de cobertura. Así que la cobertura promedio no es tan buena como se esperaba.

Mi clase de prueba es solo la predeterminada.

@RunWith(SpringRunner.class)
@SpringBootTest(classes = ElectronicGiftcardServiceApplication.class)
public class ElectronicGiftcardServiceApplicationTests {

    @Test
    public void contextLoads() {
    }
}

Entonces, ¿cómo puedo probar mi clase principal en la clase inicial de mi aplicación?

Answer 1

Puedes hacer algo como esto

@Test
public void applicationContextLoaded() {
}

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

Answer 2

Tenía el mismo objetivo (tener una prueba que ejecuta el método main ()) y me di cuenta de que simplemente al agregar un método de prueba como @ fg78nc, se dice que, de hecho, se "iniciará" la aplicación dos veces. invocación explícita de mainApp.main(new String[] {}) , que no me parece elegante.

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

SpringBootApplicationTest

package example;

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

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

  @Test
  public void contextLoads() {
  }
}

AplicaciónStartTest

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 aún se inicia dos veces, pero porque 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 la configuración de @SpringBootTest .

Answer 3

Todas estas respuestas parecen excesivas.
No agregas pruebas para hacer feliz a una herramienta métrica.
Cargar un contexto Spring de la aplicación lleva tiempo . No lo agregue en cada compilación de desarrolladores solo para ganar aproximadamente el 0,1% de la 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 declaraciones .

Primera solución: haga su clase de aplicación Spring Boot sin un bean declarado dentro. Si los tiene, muévalos a una clase de configuración (para que aún estén cubiertos por prueba de unidad). 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 la invocación main() (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 del desarrollador) y documente claramente la 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[] {});
   }
}

Answer 4

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <mainClass>your.awesome.package.Application</mainClass> 
    </configuration>
</plugin>

Si apunta a una cobertura del 100%, una cosa que puede hacer es simplemente no tener un método principal. Aún necesita una clase anotada con @SpringBootApplication pero puede estar vacía.

Tenga cuidado, ya que tiene sus inconvenientes y otras herramientas que dependen de main pueden romperse.