C贸mo probar una aplicaci贸n Spring Boot

    Introducci贸n

    Tenga en cuenta: El siguiente art铆culo estar谩 dedicado a probar las 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 bases 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 pospone u olvida a medida que los proyectos avanzan.

    驴Por qu茅 las pruebas son tan dif铆ciles de hacer de manera constante? 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 menor importancia en la mayor铆a de los equipos. Primero, crear, integrar y mantener pruebas a menudo puede ser dif铆cil. Y en segundo lugar, a menos que sea un ingeniero que haya realizado muchas pruebas y haya visto su importancia y valor, probablemente no lo colocar谩 en un lugar destacado en su lista de prioridades para aprender y formar parte de su proceso de desarrollo.

    Afortunadamente, Spring Boot est谩 haciendo que la integraci贸n y el trabajo con pruebas sea m谩s f谩cil que nunca.

    Empezando con las pruebas de Spring Boot

    Cuando se trata de pruebas, existen varios tipos diferentes de pruebas que puede escribir para ayudar a probar y automatizar el estado de su aplicaci贸n. Sin embargo, antes de que podamos comenzar a realizar pruebas, 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 spring-boot-starter-testdependencia:

    <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谩 el iniciador de pruebas es JUnit .

    JUnit ha existido durante mucho tiempo, y si alguna vez ha realizado pruebas unitarias en Java, lo m谩s probable es que haya utilizado 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 afirmaciones para ayudar a analizar los resultados de las pruebas, Spring Boot tambi茅n incorpora Hamcrest . Este marco proporciona afirmaciones y coincidencias de resultados de pruebas mejoradas, que cuando se combinan con JUnit le permiten automatizar sus pruebas de principio a fin.

    Mockito

    El siguiente marco que integra el iniciador de pruebas es Mockito . A veces, al probar, 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, usar un marco como Mockito para simular y eliminar esos objetos es la soluci贸n. De esta manera, puede continuar con sus pruebas y luego verificar qu茅 se llam贸 y qu茅 se us贸 en ese objeto despu茅s de ejecutar su prueba.

    Herramientas de Spring

    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 pruebas que permiten trabajar con JUnit, Hamcrest y Mockito dentro del entorno Spring.

    Iniciando el 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 el spring-boot-starter-testa 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, vamos a querer 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 .

    En ambos casos, agregue la webdependencia, que incluye una test-starterdependencia en su proyecto, de lo contrario, tendr谩 que agregarla manualmente:

    pom.xml:

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

    Al agregarlo manualmente, agregarlo al final del pom.xmlarchivo 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 est谩 empaquetada y empaquetada para la implementaci贸n, se ignoran las dependencias que se declaran con el alcance de la prueba. Las dependencias del alcance de la prueba solo est谩n disponibles cuando se ejecutan en los modos de desarrollo y prueba de Maven.

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

    Prueba JUnit

    Es la pr谩ctica m谩s com煤n que todo el c贸digo relacionado con las pruebas vaya a la src/test/javacarpeta. El arquetipo de Maven que gener贸 el proyecto inicialmente inclu铆a una clase de prueba llamada eg DemoApplicationTests– basada en el nombre de su clase principal, en ese mismo paquete.

    Ahora solo necesitamos algo para probar.

    Definamos un controlador simple en nuestra src/main/javacarpeta:

    HomeController:

    @RestController
    public class HomeController {
        
        @RequestMapping("/")
        public String home() {
            return "Hello World!";
        }
    }
    

    Este controlador tiene un solo m茅todo, devuelve 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 prob茅moslo y veamos si se comporta correctamente:

    JUnitControllerTest:

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

    assertEqualses un m茅todo est谩tico que proviene del org.junit.Assertpaquete, y solo uno de los assertionm茅todos utilizados en JUnit:

    asertEqualsComprueba si dos tipos u objetos primitivos son iguales.
    AsertTrueComprueba si la condici贸n de entrada es verdadera.
    aseverarFalsoComprueba si la condici贸n de entrada es falsa.
    asertNotNullComprueba si un objeto no es nulo.
    asertNullComprueba si un objeto es nulo.
    afirmar lo mismoComprueba si dos referencias a objetos apuntan al mismo objeto en la memoria.
    assertNotSameComprueba si dos referencias de objeto no apuntan al mismo objeto en la memoria.
    assertArrayEqualsComprueba si dos matrices son iguales entre s铆.

    Comenzamos nuestra prueba instanciando nuestro HomeController. No es necesario depender de la inyecci贸n de dependencia para esto. Estamos usando el assertEqualsm茅todo para verificar si el valor devuelto por nuestro m茅todo coincide con otra cadena.

    Esta es una prueba unitaria simple, pero funcional y completa. Hemos integrado los marcos de prueba, creamos una prueba JUnit marcando el m茅todo con una @Testanotaci贸n, 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 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:

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

    Otra forma en que puede ejecutar las pruebas de su proyecto ser铆a desde la l铆nea de comando o la terminal; si tiene Maven configurado en la l铆nea de comando 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:

    $ mvn test
    

    Prueba de Mockito

    La prueba anterior que creamos fue muy simple. Devolvi贸 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 de otro c贸digo administrado por Spring o es dif铆cil de construir mediante una prueba. En ese caso, podemos usar Mockito para ayudarnos a probar.

    Creemos una nueva clase de prueba dentro src/test/java:

    @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 una Userrespuesta, idas铆 que vamos a probar si hace lo que se supone que debe hacer. Comenzamos creando una instancia de nuestro controlador y luego llamando al get()m茅todo:

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

    Pedimos el Usercon el idde 1. Luego, simplemente necesitamos ejecutar una aserci贸n en el objeto devuelto para asegurarnos de que el idsea 鈥嬧媎e hecho igual a 1 como se esperaba.

    Si ejecutamos la prueba, observe los resultados:

    Nuestra prueba fall贸 con un NullPointerException. Parece que userRepositoryes igual a null.

    Esto se debe a que creamos una instancia de UserControllery no usamos Spring para inyectarlo, por lo que todos los objetos inyectados usados 鈥嬧媝or UserController, como 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 userRepositorypara que nuestra prueba funcione:

    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 @InjectMocksanotaci贸n, y esto produce un atributo privado llamado userControllerque Mockito est谩 administrando por nosotros.

    A continuaci贸n, creamos el userRepositoryobjeto simulado y esto corrige nuestro NullPointerExceptioncuando probamos 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 @Beforese ejecuta antes de cada m茅todo de prueba. El init()m茅todo se ejecuta MockitoAnnotations.initMocks(this)utilizando thisinstancia como argumento. Esto configura nuestras simulaciones antes de cada prueba.

    Pasar la thisinstancia har谩 que Mockito reconozca las @InjectMocksy las @Mocksanotaciones y que deben juntarse.

    En este caso, dado que UserControllercontiene un userRepository, el marco Mockito seguir谩 adelante y lo configurar谩 para nosotros, al igual que lo har铆a el contenedor Spring mediante la inyecci贸n de dependencias.

    Puede que le sorprenda el uso de when()en este ejemplo. Es otra staticimportaci贸n proporcionada por Mockito. Repasemos esto paso a paso y su prop贸sito quedar谩 claro.

    En primer lugar, hemos creado un new Userobjeto y lo hemos puesto iden 1. El when()m茅todo nos permite proporcionar el comportamiento de burla real. Esto le est谩 diciendo a Mockito que cuando findOnese llama al m茅todo en el repositorio, la devoluci贸n Userdebe ser apilada.

    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 ni a Spring.

    La otra caracter铆stica 煤til que ofrece Mockito es la capacidad de verifyque nuestras llamadas a m茅todos simulados o stubped se utilicen realmente durante el proceso de prueba.

    Podemos colocar una verifymarca para ver si el m茅todo stubbed realmente se llama, en nuestro caso findOne(). Esta es otra forma en la que puede desarrollar qu茅 tan bien est谩 funcionando su c贸digo.

    Si, por alguna raz贸n, el controlador llam贸 al findOne()m茅todo m谩s de una vez, la prueba fallar铆a instant谩neamente y le proporcionar铆a informaci贸n que ayudar铆a a identificar la l贸gica ofensiva y corregirla con elegancia.

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

    Puede ver que las posibilidades ahora se vuelven infinitas al probar unidades, incluso c贸digo complejo. Se necesita algo m谩s de tiempo para configurarlo, 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.

    Matchers de Hamcrest

    En la prueba anterior, usamos tanto las aserciones de JUnit para verificar los resultados de la prueba como las de Mockito verifypara asegurarnos de que los objetos simulados se llamaran correctamente. Dicho esto, 驴por qu茅 integrar otro marco para manejar 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 sus pruebas. Muchos desarrolladores est谩n comenzando a preferir el az煤car sint谩ctico de Hamcrest sobre los otros m茅todos de afirmaci贸n. Para ver c贸mo funciona Hamcrest, volvemos a MockitoControllerTestprobar ubicado en la src/test/javacarpeta:

    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 testGetUserById()caso de prueba, la prueba se realiza utilizando una aserci贸n JUnit – assertEquals. Comprueba si el valor iddel objeto devuelto coincide con 1 o no.

    Podemos cambiar esto con el assertThat()m茅todo est谩tico 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 aserci贸n JUnit anterior.

    Esto todav铆a plantea la pregunta, si l贸gicamente son 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 la prueba con solo un vistazo.

    La afirmaci贸n assertThat()es una simple comparaci贸n de igualdad, aunque Hamcrest ofrece muchas opciones y coincidencias adem谩s de esta. Incluirlos 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 consisten en probar todas las piezas de una aplicaci贸n que funcionan juntas como lo har铆an en un entorno de producci贸n o en vivo. Esto significa que nuestra aplicaci贸n esencialmente necesita 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, exist铆an algunos desaf铆os que las aplicaciones de Spring tend铆an a enfrentar.

    Problemas de pruebas de integraci贸n

    Aplicaciones tradicionales de Spring

    Los contenedores son dif铆ciles de probar:

    Cualquier c贸digo que sea parte de su aplicaci贸n que se base en el 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 alg煤n Otra manera.

    Spring Context debe estar disponible:

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

    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 se ejecutan naturalmente 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 requerido para ejecutarlas todas puede aumentar dr谩sticamente.

    El estado de la base de datos debe ser coherente:

    Si sus pruebas de integraci贸n est谩n modificando la base de datos, o si espera 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 Spring Boot

    Sin contenedor, m谩s f谩cil de 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 lidiar con 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 tradicionales de Spring es el uso de arrancadores y la configuraci贸n autom谩tica. Esto facilita un poco el apuntalamiento del contenedor Spring con Spring Boot.

    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 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 formas de asegurarse de que su aplicaci贸n, en su conjunto, funciona 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, hay realmente dos cosas b谩sicas que debe hacer.

    La primera es que debe anotar sus pruebas con la @RunWithanotaci贸n y especificar que desea ejecutarlas con el SpringJUnit4ClassRunner.class.

    El segundo es que debe agregar la @SpringApplicationConfigurationanotaci贸n y proporcionar su clase Spring Boot principal para su aplicaci贸n.

    Esta prueba se encargar谩 de probar el UserRepositoryobjeto Spring Data:

    @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 le pide al repositorio a todos los usuarios, y luego usa Hamcrest para asegurarse de que la lista de retorno sea mayor o igual a 0. Ahora, cuando se inicie la prueba, se cargar谩 el contexto Spring y Spring inyectar谩 el total userRepositoryen la prueba, tal como lo har铆a si se ejecutara en una aplicaci贸n est谩ndar.

    Independientemente del resultado de la prueba, exitoso o no, abra la pesta帽a de la 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 realmente comienza con pruebas de integraci贸n. B谩sicamente, 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 llevar un tiempo si tiene una aplicaci贸n realmente grande o si tiene muchas pruebas.

    Puede pensar que ha alcanzado el cenit de las pruebas con Spring Boot, pero hay un 谩rea que todav铆a no cubrimos en absoluto y es la API REST real que exponen sus controladores.

    Ahora que a JavaScript, MVC y a las aplicaciones m贸viles les gusta tener una API REST con la que hablar, en lugar de una p谩gina JSP con plantilla, es bueno poder probar esa API real. Eso, a su vez, prueba toda la pila del lado del servidor. 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 src/test/javacarpeta cree una clase:

    @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: RestTemplatec贸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 retiene la respuesta. Aunque codifiqu茅 la URL del servidor aqu铆 con fines de tutorial, esto es algo que podr铆a, y definitivamente deber铆a mover al application.propertiesarchivo, o configurar sus pruebas para que apunte a su entorno de prueba, en lugar de su entorno de desarrollo.

    A continuaci贸n, ejecutamos una aserci贸n para asegurarnos de obtener una 200 OKdevoluci贸n como respuesta; si no, la prueba fallar谩 inmediatamente.

    Luego, queremos convertir la respuesta en un objeto JSON real y realizar afirmaciones 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, lo comprobaremos para asegurarnos de que obtengamos una matriz vac铆a como nuestra carga 煤til JSON equalTo("[]").

    Nuevamente, estas pruebas son muy costosas de ejecutar, por lo que pueden ser algo que desee configurar solo en un servidor de compilaci贸n continua y ejecutarlas cada vez que alguien de su equipo verifique
    algo o agregue 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, puede y debe dedicar un tiempo a examinar cada uno de los marcos por su cuenta, ya que proporcionan herramientas realmente 煤tiles para el desarrollo.

    Comenzar a escribir pruebas en sus proyectos realmente no requiere mucho esfuerzo cuando se integra con Spring Boot. Empiece a adquirir el h谩bito de probar porque definitivamente lo diferenciar谩 de otros desarrolladores. Le 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 a pesar de que hemos cubierto ligeramente lo que es posible, debe acostumbrarse a 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 haga, m谩s f谩cil ser谩 con el tiempo.

    Recuerde que Spring Boot tiene que ver con la gesti贸n de dependencias con sus iniciadores. Esos iniciadores a menudo proporcionan 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 utilizando el application.propertiesarchivo. Spring Boot lo libera de las implementaciones de contenedores al incrustar el contenedor dentro de la aplicaci贸n, por lo que ahora puede ejecutar su aplicaci贸n Java en cualquier lugar. Esto facilita mucho las implementaciones en la nube o cosas como probar su aplicaci贸n.

    Aseg煤rese de tomarse un tiempo y consultar la documentaci贸n oficial de prueba de Spring Boot para obtener m谩s informaci贸n.

     

    Etiquetas:

    Deja una respuesta

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