Pruebas unitarias, de integración y más

Vamos aclarar el concepto de este tipo de pruebas usadas en el mundo del desarrollo de software.

Rodríguez Patiño, Eduardo
2020-09-28 | 577 lecturas

La mejor forma de corroborar que nuestro software funciona correctamente es a través de las pruebas; por lo tanto, no deben esperar subir hasta producción y que el cliente reporte el bug.

¿Pero que prueba sería la más correcta para mi aplicación?

¿Qué vamos aprender?

Vamos a entender la diferencia entre los tipos de pruebas que hay en el mundo del desarrollo de software para que puedan tener claro el concepto de esta y las puedan implementar en sus proyectos.

Pruebas unitarias

Este tipos de pruebas analiza el código como unidad como podría ser el método de una clase.

Por ejemplo, un método de una clase para autenticarnos la sometemos a diversas pruebas para evitar que en un futuro el comportamiento de esta se vea alterado por el cambio o actualización del código de otro programador.

¿Qué pruebas podríamos pensar?

  • ¿Qué debería responder cuando las credenciales son correctas?
  • ¿Qué debería pasar cuando las credenciales son incorrectas?
  • ¿Qué pasaría si ingreso el nombre de usuario en mayúscula?

Y así sucesivamente podemos ir planteando las pruebas, la idea de esto que cualquier cambio de nuestro código este respaldado por las pruebas planteadas.

Pueden leer más sobre las pruebas unitarias en nuestra siguiente entrada.

Pruebas de integración

Similar a la anterior pero ya no analizamos el código como unidad, sino como conjunto como podría decir un flujo completo.

Por ejemplo, regresando a la prueba para validar el flujo de autenticación ya no analizaríamos solo el método sino más bien podríamos realizar la prueba desde la llamada de la API hasta cuando consulta a la base de datos para validar la autenticación.

Muchos programadores confunden este tipo de pruebas al querer cubrir demasiada funcionalidad en una prueba unitaria cuando realmente lo estan enfocando más a un integration test o prueba de integración.

Otros tipos de pruebas

Vamos analizar otras pruebas adicionales que usualmente las suelen hacer nuestros "queridos" amigos de QA.

Pruebas funcionales

Este tipo de prueba lo debemos ver desde la perspectiva del usuario final o cliente, es decir que la funcionalidad solicitada cumpla con lo que demandado.

Usualmente estas pruebas se hacen a mano pero para agilizar esto podríamos hacer uso de Cypress.

Imaginate que nuestro QA necesita volver a probar el flujo de creación de usuarios pero en vez de estar haciéndolo manualmente el puede programar todo para que la interacción se haga automática a través del browser.

Pruebas de estrés

Someter al software a pruebas extremas para ver como responde a una caída, alta concurrencia, etc.

Pruebas de aceptación

Estas pruebas usualmente son realizadas por el cliente para corroborar que los cambios realizados son los esperados.

Allá por el 2015 teníamos un ambiente pre-producción pero solo para el cliente, es decir aparte de tener STAGING que era para nosotros, el cliente tenía su propio STAGING (nosotros nunca lo tocabamos) para que puedan revisar que todo lo realizado funcione como se espera antes de que se pueda pasar a su ambiente de producción real.