Cómo probar una aplicación Spring Boot

Tenga en cuenta: el siguiente artículo estará dedicado a probar aplicaciones Spring Boot. Se supone que está familiarizado al menos con los conceptos básicos de Java,...

Introducción

Tenga en cuenta: El siguiente artículo estará dedicado a probar aplicaciones Spring Boot. Se supone que está familiarizado con al menos los conceptos básicos de Java, Maven y Spring Boot (Controladores, Dependencias, Repositorio de base de datos, etc.).

Hay una falta general de pruebas en la mayoría de las organizaciones. Tal vez incluso su equipo sea uno de esos equipos que tienen buenas intenciones en las pruebas, pero siempre se posponen o se olvidan a medida que los proyectos se ponen en marcha.

¿Por qué las pruebas son tan difíciles de hacer consistentemente? Los beneficios de las pruebas son bien conocidos y, sin embargo, ¿por qué se pasan por alto con tanta frecuencia?

Creo que hay un par de razones por las que las pruebas tienen menos importancia en la mayoría de los equipos. Primero, la creación, integración y mantenimiento de pruebas a menudo puede ser difícil. Y segundo, a menos que sea un ingeniero que haya realizado muchas pruebas y haya visto su importancia y valor, probablemente no lo ubicará en un lugar destacado de su lista de prioridades para aprender y formar parte de su proceso de desarrollo.

Afortunadamente, Bota de primavera está facilitando más que nunca la integración y el trabajo con las pruebas.

Primeros pasos con las pruebas de Spring Boot

Cuando se trata de pruebas, hay varios tipos diferentes de pruebas que puede escribir para ayudar a probar y automatizar la salud de su aplicación. Sin embargo, antes de que podamos comenzar a realizar cualquier prueba, debemos integrar los marcos de prueba.

Con Spring Boot, eso significa que necesitamos agregar un iniciador a las dependencias de nuestro proyecto, para las pruebas solo necesitamos agregar la dependencia spring-boot-starter-test:

1
2
3
4
5
6
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <version>{version}</version>
    <scope>test</scope>
</dependency>

Esta dependencia única lo preparará para la mayoría de sus necesidades de prueba.

JUnit y Hamcrest

El primer marco que integrará Test Starter es JUnit.

JUnit ha existido durante mucho tiempo, y si alguna vez ha probado la unidad en Java, lo más probable es que haya usado este marco antes. Al realizar pruebas unitarias básicas, JUnit y Spring se complementan bien, como verá en algunas demostraciones próximas. Aunque JUnit proporciona cierto soporte de afirmación para ayudar a analizar los resultados de las pruebas, Spring Boot también incorpora Hamcrest. Este marco proporciona aserciones y coincidencias de resultados de prueba mejoradas, que cuando se combinan con JUnit le permiten automatizar sus pruebas de principio a fin.

Mockito

El siguiente marco que integra Test Starter es Mockito. A veces, cuando se prueba, el código que está tratando de probar es una dependencia de otro objeto. A veces, es simplemente un fragmento de código que es difícil de respaldar para una prueba unitaria. En tales casos, la solución es usar un marco como Mockito para simular y aplicar stub a esos objetos. De esta manera, puede continuar con sus pruebas y luego verificar qué se llamó y usó en ese objeto después de ejecutar su prueba.

Herramientas de resorte {#herramientas de resorte}

Por último, la dependencia del iniciador de prueba extrae las herramientas de prueba de Spring.

Estos incluyen anotaciones, utilidades de prueba y otro soporte de integración de prueba que permite trabajar con JUnit, Hamcrest y Mockito dentro del entorno Spring.

Inicio del proyecto Spring Boot

En el resto de este artículo, configuraremos y trabajaremos con diferentes aspectos de prueba en nuestra aplicación Spring Boot.

En esta sección, vamos a configurar nuestra aplicación y entorno para realizar pruebas. Lo primero que debe suceder es agregar spring-boot-starter-test a las dependencias de nuestro proyecto.

Solo después de agregarlo, podemos crear una prueba unitaria simple para ver cómo funcionan los conceptos básicos. Luego, querremos cubrir un par de formas diferentes en las que puede ejecutar pruebas dentro de Spring Boot.

Puede crear el proyecto Spring Boot a través de su IDE o generarlo usando [Spring Initializr] (https://start.spring.io/).

En ambos casos, agregue la dependencia web, que incluye una dependencia test-starter en su proyecto; de lo contrario, tendrá que agregarla manualmente:

pom.xml:

1
2
3
4
5
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
</dependency>

Al agregarlo manualmente, agregarlo al final del archivo pom.xml hará que Maven extraiga todas sus dependencias de recursos de prueba.

Una cosa a tener en cuenta sobre esta dependencia es que incluye el alcance de la prueba <scope>test</scope>. Eso significa que cuando la aplicación se empaqueta y empaqueta para su implementación, se ignoran las dependencias que se declaran con el ámbito de prueba. Las dependencias del alcance de la prueba solo están disponibles cuando se ejecutan en los modos de prueba Maven y desarrollo.

Ahora que tenemos nuestras bibliotecas de prueba en su lugar, podemos continuar y crear una prueba.

Pruebas JUnit

Es la práctica más común que todo el código relacionado con las pruebas vaya a la carpeta src/test/java. El arquetipo Maven que generó el proyecto inicialmente incluía una clase de prueba llamada, p. DemoApplicationTests - basado en el nombre de su clase principal, en ese mismo paquete.

Ahora solo necesitamos algo para probar.

Definamos un controlador simple en nuestra carpeta src/main/java:

Controlador de inicio:

1
2
3
4
5
6
7
8
@RestController
public class HomeController {
    
    @RequestMapping("/")
    public String home() {
        return "Hello World!";
    }
}

Este controlador tiene un único método, devolviendo una cadena, que se ejecuta cuando accedemos a la raíz de nuestra aplicación. Se espera ese tipo de comportamiento de este controlador, pero vamos a probarlo y ver si se comporta correctamente:

JunitControllerPrueba:

1
2
3
4
5
6
7
8
9
public class JUnitControllerTest {

    @Test
    public void testHomeController() {
        HomeController homeController = new HomeController();
        String result = homeController.home();
        assertEquals(result, "Hello World!");
    }
}

assertEquals es un método estático del paquete org.junit.Assert, y solo uno de los métodos asertion utilizados en JUnit:


afirmarEquals Comprueba si dos tipos primitivos u objetos son iguales. assertTrue Comprueba si la condición de entrada es verdadera. assertFalse Comprueba si la condición de entrada es falsa. assertNotNull Comprueba si un objeto no es nulo. assertNull Comprueba si un objeto es nulo. assertSame Comprueba si dos referencias a objetos apuntan al mismo objeto en la memoria. assertNotSame Comprueba si dos referencias a objetos no apuntan al mismo objeto en la memoria. afirmarArrayEquals Comprueba si dos matrices son iguales entre sí.


Comenzamos nuestra prueba instanciando nuestro HomeController. No hay necesidad de confiar en la inyección de dependencia para esto. Estamos usando el método assertEquals para comprobar si el valor devuelto por nuestro método coincide con otra cadena.

Esta es una prueba unitaria simple, pero funcional y completa. Integramos los marcos de prueba, creamos una prueba JUnit marcando el método con una anotación @Test después de lo cual realizamos una afirmación de prueba.

Ahora, se supone que debemos ejecutar la prueba y observar el resultado, y hay varias formas de ejecutar las pruebas:

La primera forma es simplemente hacer clic con el botón derecho en toda la prueba o en el nombre de la prueba si desea ejecutar una sola prueba. Luego, seleccione "Ejecutar como JUnit". Esto comienza la prueba en su IDE:

Run JUnit test{.img-responsive}

Prueba JUnit superada{.img-responsive}

Si modificamos nuestra prueba y las cadenas ya no coinciden, se nos solicitará un tipo de resultado diferente:

Falló la prueba JUnit{.img-responsive}

Otra forma de ejecutar las pruebas de su proyecto sería desde la línea de comandos o la terminal: si tiene Maven configurado en la línea de comandos y está trabajando con Maven, puede ejecutar el comando de prueba de Maven desde la raíz de su proyecto para obtener los mismos resultados:

1
$ mvn test

Pruebas simuladas

La prueba anterior que creamos era muy simple. Devolvió algo de texto estático, por lo que fue bastante fácil de probar.

A medida que las aplicaciones crecen en complejidad, no puede simplemente probar unidades de esta manera. El código que está probando puede tener dependencias en otro código administrado por Spring o que es difícil de construir a través de una prueba. En ese caso, podemos usar Mockito para ayudarnos a probar.

Vamos a crear una nueva clase de prueba dentro de src/test/java:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
@RestController
@RequestMapping("api/v1/")
public class UserController {

    @Autowired
    private UserRepository userRepository;

    @RequestMapping(value = "user/{id}", method = RequestMethod.GET)
    public User get(@PathVariable Long id) {
        return userRepository.findOne(id);
    }
}

El objetivo de este método es obtener un ‘Usuario’ por su ‘id’, así que vamos a probar si hace lo que se supone que debe hacer. Comenzamos instanciando nuestro controlador y luego llamando al método get():

1
2
3
4
5
6
7
8
9
public class MockitoControllerTest {

    @Test
    public void testGetUserById() {
        UserController userController = new UserController();
        User user = userController.get(1L);
        assertEquals(1l, user.getId().longValue());
    }
}

Pedimos el Usuario con el id de 1. Luego simplemente necesitamos ejecutar una aserción en el objeto devuelto para asegurarnos de que el id es realmente igual a 1 como se esperaba.

Si ejecutamos la prueba, observe los resultados:

Prueba de Mockito fallida{.img-responsive}

Nuestra prueba falló con una NullPointerException. Parece que userRepository es igual a null.

Esto se debe a que instanciamos el UserController y no usamos Spring para inyectarlo, por lo que todos los objetos inyectados utilizados por el UserController, como el userRepository, nunca fueron creados correctamente por Spring.

Este es el problema exacto para el que se crearon los marcos simulados. Al usar Mockito, podemos simular el userRepository para que podamos hacer que nuestra prueba funcione:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class MockitoControllerTest {

    @InjectMocks
    private UserController userController;

    @Mock
    private UserRepository userRepository;

    @Before
    public void init() {
        MockitoAnnotations.initMocks(this);
    }

    @Test
    public void testGetUserById() {
        User u = new User();
        u.setId(1l);
        when(userRepository.findOne(1l)).thenReturn(u);

        User user = userController.get(1L);

        verify(userRepository).findOne(1l);

        assertEquals(1l, user.getId().longValue());
    }
}

En lugar de instanciar el UserController, queremos crear una instancia simulada de él. Mockito proporciona una anotación que crea este objeto y lo inyecta en la prueba. Usamos la anotación @InjectMocks, y esto produce un atributo privado llamado userController que Mockito administra por nosotros.

A continuación, creamos el objeto simulado userRepository y esto corrige nuestra NullPointerException al probar el controlador. Usamos otra anotación de Mockito para eso: @Mock.

A continuación, agregamos el método de configuración que inicializa todos los objetos simulados juntos cuando se ejecuta la prueba. El método anotado con @Before se ejecuta antes de cada método de prueba. El método init() ejecuta MockitoAnnotations.initMocks(this) usando la instancia this como argumento. Esto configura nuestros simulacros antes de cada prueba.

Pasar la instancia this hará que Mockito reconozca las anotaciones @InjectMocks y @Mocks y que deben juntarse.

En este caso, dado que el UserController contiene un UserRepository, el marco Mockito seguirá adelante y lo configurará para nosotros, al igual que lo haría el contenedor Spring a través de la inyección de dependencia.

Puede que te sorprenda el uso de when() en este ejemplo. Es otra importación estática proporcionada por Mockito. Repasemos esto paso a paso y su propósito será claro.

En primer lugar, hemos creado un objeto nuevo usuario y establecemos el id en 1. El método when() nos permite proporcionar el comportamiento de burla real. Esto le dice a Mockito que cuando se llama al método findOne en el repositorio, el Usuario devuelto debe ser aplicado.

Lo que esto significa es que la clase devuelta es falsa con valores de retorno preprogramados y no un objeto devuelto real de la base de datos. Esto nos permite probar la unidad sin tener que conectarnos a la base de datos o a Spring.

La otra función útil que ofrece Mockito es la capacidad de “verificar” que nuestras llamadas de método simuladas o stub se utilicen realmente durante el proceso de prueba.

Podemos colocar una verificación verify para ver si realmente se llama al método stubbed, en nuestro caso findOne(). Esta es otra forma más en la que puede desarrollar qué tan bien está funcionando su código.

Si, por alguna razón, el controlador llamara al método findOne() más de una vez, la prueba fallaría instantáneamente y le brindaría información que ayudaría a identificar la lógica infractora y corregirla correctamente.

Después de aplicar estos cambios, volver a ejecutar la prueba dará como resultado un hermoso pase verde:

Prueba de Mockito al pasar la verificación{.img-responsive}

Puede ver que las posibilidades ahora se vuelven infinitas cuando se prueban unidades, incluso código complejo. La configuración lleva un poco más de tiempo, pero ahora puede probar controladores, servicios o cualquier otro tipo de objeto, sin tener que ejecutar una prueba de integración que inicie el contenedor Spring.

Las pruebas unitarias con objetos simulados son rápidas, mucho más rápidas que las pruebas de integración.

Emparejadores Hamcrest

En la prueba anterior, usamos las aserciones de JUnit para verificar los resultados de la prueba, así como la verificación de Mockito para asegurarnos de que los objetos simulados se llamaran de manera adecuada. Dicho esto, ¿por qué integrar otro marco para manejar solo la coincidencia y las afirmaciones de los resultados de las pruebas?

Hamcrest proporciona un enfoque declarativo más legible para afirmar y hacer coincidir los resultados de su prueba. Muchos desarrolladores están comenzando a preferir el azúcar sintáctico de Hamcrest sobre los otros métodos de aserción. Para ver cómo funciona Hamcrest, volvemos a la prueba MockitoControllerTest ubicada en la carpeta src/test/java:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.*;

public class MockitoControllerTest {

    @InjectMocks
    private UserController userController;

    @Mock
    private UserRepository userRepository;

    @Before
    public void init() {
        MockitoAnnotations.initMocks(this);
    }

    @Test
    public void testGetUserById() {
        User u = new User();
        u.setId(1l);
        when(userRepository.findOne(1l)).thenReturn(u);

        User user = userController.get(1L);

        verify(userRepository).findOne(1l);

        //assertEquals(1l, user.getId().longValue());
        assertThat(user.getId(), is(1l));
    }
}

En el caso de prueba testGetUserById(), la prueba se realiza utilizando una aserción JUnit - assertEquals. Comprueba si el id del objeto devuelto coincide con 1 o no.

Podemos cambiar esto con el método estático assertThat() de Hamcrest. Tenga en cuenta que la lógica de la prueba, así como el código que se está probando, permanecen intactos; de hecho, la nueva línea es lógicamente equivalente a la afirmación anterior de JUnit.

Esto todavía plantea la pregunta, si son lógicamente iguales, ¿por qué incluir otro marco? Comparando estas dos afirmaciones, es evidente que la afirmación de Hamcrest es más legible y menos ofensiva para los ojos. Además, es más fácil ver cuál es el objetivo final de la afirmación de prueba con solo un vistazo.

La afirmación assertThat() es una simple comparación de igualdad, aunque Hamcrest proporciona muchas opciones y comparaciones además de esta. Incluirlos a todos en una tabla sería una locura, así que consulte la documentación oficial de Hamcrest si está interesado en leer sobre ellos.

Pruebas de integración

El último tipo de prueba que cubriremos es el concepto de Prueba de integración.

Las pruebas de integración tienen que ver con probar todas las piezas de una aplicación que funcionan juntas como lo harían en un entorno en vivo o de producción. Esto significa que nuestra aplicación esencialmente debe estar ejecutándose para probarla. Debido a la naturaleza de las pruebas de integración, esto plantea algunos desafíos al crear y ejecutar este tipo de pruebas.

Antes de Spring Boot, había algunos desafíos con los que las aplicaciones Spring tendían a enfrentarse.

Problemas de prueba de integración {#problemas de prueba de integración}

Aplicaciones Spring tradicionales

Los contenedores son difíciles de probar:

Cualquier código que sea parte de su aplicación que dependa del contenedor o la especificación del servlet es difícil de probar porque necesita probar el inicio del contenedor y ejecutar pruebas en él, o necesita simular el contenedor y emularlo en de alguna otra manera.

El contexto de primavera debe estar disponible:

Dado que Spring Core, Spring Beans y la inyección de dependencia requieren que Spring se ejecute y administre esas piezas en su contexto de aplicación. Todas las pruebas de integración deben garantizar que el contexto de la aplicación Spring se está ejecutando.

El inicio de la aplicación/prueba puede ser lento:

Iniciar el contexto de Spring y ejecutar o emular el contenedor puede llevar tiempo en aplicaciones más grandes. Las pruebas de integración, naturalmente, se ejecutan más lentamente que las pruebas unitarias simples. Puede imaginar que a medida que agrega más y más pruebas de integración, el tiempo de prueba necesario para ejecutarlas todas puede aumentar drásticamente.

El estado de la base de datos debe ser consistente:

Si sus pruebas de integración modifican la base de datos, o esperan que ciertos datos en la base de datos estén allí para su caso de prueba, entonces puede tener problemas si no puede hacer que su base de datos se mantenga consistente cada vez que ejecuta sus pruebas.

Aplicaciones de arranque de primavera {#aplicaciones de arranque de primavera}

Sin contenedor, más fácil iniciar la aplicación:

Debido a que las aplicaciones Spring Boot se pueden iniciar como una aplicación Java simple, se elimina la complejidad de manejar un contenedor e implementar su aplicación. Por supuesto, Spring Boot todavía tiene un contenedor integrado, pero Spring Boot simplemente hace que iniciar y manejar su aplicación sea mucho más fácil.

Configuración automática de Spring Context:

Las pruebas de integración en Spring Boot aún necesitan tener un contexto Spring. La principal diferencia entre Spring Boot y las aplicaciones Spring tradicionales es el uso de arrancadores y la configuración automática. Esto hace que apuntalar el contenedor Spring con Spring Boot sea un poco más fácil.

El inicio de la aplicación/prueba puede ser lento:

El inicio de la prueba de integración y el tiempo de ejecución siguen siendo problemas en el entorno Spring Boot. Cuanto más grande sea su aplicación y más componentes de Spring tenga, más tiempo llevará iniciar su aplicación.

El estado de la base de datos debe ser coherente:

La consistencia de la base de datos también sigue siendo un problema con las pruebas de Spring Boot.

Con todos estos problemas, las pruebas de integración siguen siendo una de las mejores maneras de asegurarse de que su aplicación, en su conjunto, funcione según lo previsto y diseñado.

Cuando se trata de pruebas de integración, las aplicaciones Spring Boot realmente comienzan a brillar sobre las aplicaciones Spring convencionales. Para convertir cualquier prueba JUnit en una prueba de integración adecuada, en realidad hay dos cosas básicas que debe hacer.

La primera es que debe anotar sus pruebas con la anotación @RunWith y especificar que desea ejecutarlas con SpringJUnit4ClassRunner.class.

La segunda es que necesita agregar la anotación @SpringApplicationConfiguration y proporcionar su clase Spring Boot principal para su aplicación.

Esta prueba se encargará de probar el objeto Spring Data UserRepository:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(Demo.class)
public class UserRepoIntegrationTest {
    @Autowired
    private UserRepository userRepository;

    @Test
    public void testFindAll() {
        List<User> users = userRepository.findAll();
        assertThat(users.size(), is(greaterThanOrEqualTo(0)));
    }
}

Esta prueba pregunta al repositorio por todos los usuarios y luego usa Hamcrest para asegurarse de que la lista de retorno sea mayor o igual a 0. Ahora, cuando la prueba se inicie, el contexto de Spring se cargará y Spring inyectará el userRepository completo en la prueba, tal como lo haría si se estuviera ejecutando en una aplicación estándar.

Independientemente del resultado de la prueba, exitoso o fallido, abra la pestaña Consola IDE y debería notar que parece que su aplicación se inició (logotipo de Spring, información, etc.). Esto sucede porque nuestra aplicación en realidad comienza con pruebas de integración. Esencialmente, cada prueba de integración iniciará su aplicación, y esta es una de las razones por las que las pruebas de integración pueden demorar un tiempo si tiene una aplicación realmente grande o tiene muchas pruebas.

Puede pensar que ha alcanzado el cénit de las pruebas con Spring Boot, pero hay un área que todavía no cubrimos en absoluto y esa es la API REST real que exponen sus controladores.

Ahora que a JavaScript, MVC y aplicaciones móviles les gusta tener una API REST con la que comunicarse, en lugar de una página JSP con plantilla, es bueno poder probar esa API real. Eso, a su vez, prueba toda su pila del lado del servidor. Así que este es el concepto de una prueba de integración web.

Spring proporciona una anotación simple que marca una prueba de integración como una prueba de integración web @WebIntegrationTest. Como de costumbre, dentro de su carpeta src/test/java cree una clase:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(Demo.class)
@WebIntegrationTest
public class UserControllerWebIntegrationTest {

    @Test
    public void testListAll() throws IOException {
        RestTemplate restTemplate = new TestRestTemplate();
        ResponseEntity<String> response = restTemplate.getForEntity("http://localhost:8080/api/v1/users", String.class);

        assertThat(response.getStatusCode(), equalTo(HttpStatus.OK));

        ObjectMapper objectMapper = new ObjectMapper();
        JsonNode responseJson = objectMapper.readTree(response.getBody());

        assertThat(responseJson.isMissingNode(), is(false));
        assertThat(responseJson.toString(), equalTo("[]"));
    }
}

Lo primero que estamos haciendo es crear una plantilla REST: RestTemplate es cómo podemos llamar mediante programación a las API y, en este caso, queremos llamar mediante programación a la API de usuario.

La llamada a la API solicita a todos los usuarios del sistema y contiene la respuesta. Aunque codifiqué la URL del servidor aquí para fines de tutorial, esto es algo que podría, y definitivamente debería pasar al archivo application.properties, o configurar sus pruebas para que apunte a su entorno de prueba, en lugar de su entorno de desarrollo.

A continuación, ejecutamos una afirmación para asegurarnos de que recibimos un 200 OK como respuesta, y si no, la prueba fallará inmediatamente.

Luego queremos convertir la respuesta en un objeto JSON real y realizar aserciones en él para asegurarnos de que el objeto JSON devuelto esté en un estado que tenga sentido para nuestra aplicación.

Dado que nuestra base de datos en realidad no contiene ningún usuario y, francamente, no existe, verificaremos para asegurarnos de obtener una matriz vacía como nuestra carga JSON: equalTo ("[]" ).

Nuevamente, estas pruebas son muy costosas de ejecutar, por lo que es posible que desee configurarlas solo en un servidor de compilación continua y ejecutarlas cada vez que alguien de su equipo verifique
algo en o agrega algo a su repositorio de código.

Conclusión

Dado que Spring Boot integra JUnit, Mockito y Hamcrest, quería cubrir cómo usar estas herramientas dentro de una aplicación Spring Boot. Al igual que la mayoría de los marcos que hemos incluido con nuestros casos de prueba de Spring Boot, podría y debería dedicar algún tiempo a analizar cada uno de los marcos por separado, ya que proporcionan herramientas realmente útiles para el desarrollo.

Comenzar a escribir pruebas en sus proyectos realmente no requiere mucho esfuerzo cuando se está integrando con Spring Boot. Comience a adquirir el hábito de realizar pruebas porque definitivamente lo diferenciará de otros desarrolladores. Ayudará a escribir código de mayor calidad, ya que esencialmente hará una revisión del código de su propio trabajo mientras intenta probarlo.

Como ha visto con los ejemplos que hemos cubierto, hay muchas opciones con las pruebas en una aplicación Spring Boot. Y aunque hemos cubierto ligeramente lo que es posible, debe adquirir el hábito de escribir algunas pruebas para parte del código que produce en su aplicación, incluso si todavía está aprendiendo y probando con el código. Cuanto más hagas, más fácil te resultará con el tiempo.

Recuerde que Spring Boot tiene que ver con la gestión de dependencias con sus iniciadores. Esos iniciadores a menudo brindan una configuración automática que integra los marcos en su aplicación de manera fácil y rápida.

Luego puede anular y personalizar las necesidades de la aplicación usando el archivo application.properties. Spring Boot lo libera de las implementaciones de contenedores al incorporar el contenedor dentro de la aplicación, por lo que ahora puede ejecutar su aplicación Java en cualquier lugar. Esto hace que las implementaciones en la nube o cosas como probar su aplicación sean mucho más fáciles.

Asegúrese de tomarse el tiempo y consultar la documentación de prueba de la bota primavera oficial para obtener más información. . n. .