Antes de comenzar con el curso es muy importante repasar el concepto de pruebas, esto para lograr entender mejor qué es lo que estamos haciendo y porqué lo hacemos de esa manera.
Imaginemos el siguiente escenario:
Tenemos un restaurante que hace platillos con huevos
Entre nuestros platillos están:
Omelettes de espinacas
Huevos revueltos con tocino
Huevos estrellados con arroz
Dicho esto, podemos suponer dos cosas, que sólo nos alcanza para huevos o que somos muy buenos haciendo huevos.
Partamos de la segunda opción. Si somos muy buenos haciendo huevos significa que todos los aspectos de mis platillos con huevo tienen una calidad superior garantizada.
Justamente eso es lo que hacemos en el desarrollo de software. Al momento de hacer un proyecto, estamos acatando requerimientos en específico ( puede ser un restaurante que solo haga platillos con huevo ) y con herramientas en específico.
Es nuestro deber asegurar la calidad de nuestro código y de nuestra solución. La manera en que nosotros hacemos eso es mediante las pruebas.
Vamos a hacer dos tipos de pruebas que van a garantizar que cumplas con todos los requisitos para ser un crack en la calidad de tu código.
Pruebas unitarias
Regresando al escenario del restaurante, para hacer un buen omelette necesito si o si huevos, y huevos en buen estado, no podridos ni rotos.
Así que lo primero que hago para garantizar la calidad de mi omelette, es revisar que mis huevos pasen el estándar de calidad que requiero.
En código nuestros huevos son todas las piezas atómicas de código que tenemos, e.g.
Una función
Un evento
Un botón
etc.
Y el hacer pruebas unitarias involucra probar individualmente que estos módulos cumplan con su función bajo los estándares, si te estás preguntando cuáles son los estándares, no te preocupes, en un momento los explicaremos.
Pruebas de integración
Las pruebas de integración serán nuestro omelette de espinacas.
Al ya haber probado que nuestros huevos están en buenas condiciones, al igual que la espinaca, pasamos a integrarlos y formar un omelette.
Las pruebas de integración involucran procesos y no piezas atómicas de código.
Imagínate que al hacer el omelette nos damos cuenta de que el huevo que estamos usando es de codorniz y que tenemos más de 10kg de espinaca.
Si lo viéramos desde la perspectiva de las pruebas unitarias, tanto el huevo como la espinaca pasaron las pruebas, pero al momento de integrarlo para el proceso final, no tienen realmente sentido y generan fallos en nuestro sistema
En código se puede traducir a la forma en que una funcionalidad influye en el proceso completo de una aplicación; puede que nuestro código funcione sobre eventos. El tener pruebas de integración, garantiza que cuando lancemos esos eventos, no se rompa nada de nuestro código.
Es muy fácil pasar por alto estas pruebas cuando no se tiene el panorama completo de nuestra aplicación, es por ello que como buenos desarrolladores debemos saber que es lo que nuestro código hace a todo el sistema, no solamente quedarnos con que nuestra función sirva.
Estándares
Hay varias instituciones que marcan estándares de cómo se deben crear y documentar las pruebas, entre el más usado es el IEEE Std 1008, Software Unit Testing, si quieres más información de este estándar puedes ingresar a este link, pero hay algo más que pauta el estándar de tu código, y es el cliente.
Realmente, la calidad de tu código y de tus procesos se diseñan pensando en resolver los requerimientos de los clientes. Ojo, tus clientes no necesariamente son los usuarios finales, en muchos casos son tus lideres de proyecto.
Pongamos un último ejemplo del restaurante, supongamos que aparte de ser fan de los huevos, eres fan de la pimienta, pero resulta que tu lider administrativo te comenta que la pimienta ha subido de precio exorbitantemente, por lo cual ya no podemos ponerle mucha pimienta.
De esa manera, cambiaron los estándares de calidad de mi producto, no por una decisión de los clientes finales, sino más bien por una de mi lider administrativo.
Hablando técnicamente los requerimientos de los programas cambian constantemente y más en la actualidad con tantas formas de trabajo ágiles, un día nuestro estándar de calidad puede ser que nuestro código pese 400 KB y el siguiente mes baja a 300 KB, por lo cual es super importante tener en cuenta el proceso de testing desde etapas tempranas del diseño de un proyecto.
Y a final de todo, lo que estamos generando es tener calidad en el desarrollo de nuestro software y eso nos va a ayudar a ser mejores desarrolladores.
En la siguiente clase ahondaremos más en la historia y el impacto de las pruebas en nuestro mundo actual.
Pon en los comentarios, algún otro ejemplo que se te venga a la mente sobre pruebas unitarias y de integración en tu día a día.
Aportes 6
Preguntas 0
Ordenar por:
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?
Se me ocurre en una banda musical, cuando un integrante practica la cancion seria la prueba unitaria. Si logra tocarla de principio a fin habras pasado tu prueba unitaria.
Luego viene la prueba de integracion, tocar con los demas musicos la pieza de principio a fin seria la prueba de integracion. Me encanta la musica y soy musico!
Realmente no hago pruebas de ningún tipo pero usando el tenor de ellos puedo decir que hago unit testing frecuentemente de manera que creo una función y me aseguro que haga lo que tenga que hacer y al hacer click en mi botón de pruebas la función se llame adecuadamente.
Y mi prueba de integración al ver que todo funcione en orden en conjunto.
Vale, en resumen, las pruebas unitarias son las pruebas que me permiten probar las funcionalidades específicas de mi código, y las pruebas de integración son las que me permiten probar que todas esas funciones en conjunto hagan lo que yo necesito que mi aplicación haga.
Y nuestro código se rige en estándares, que son básicamente las reglas que me dicen cómo tener un código más prolijo y aumentan la calidad de mi código incluso pudiendo hacer que pese menos, y el testing me ayudará a no romper nada en mi aplicación mientras aplico esos estándares ya que constantemente estaré mejorando mi código y necesito una forma de asegurar que nada se romperá (El testing)😄!
Siento que un error de integración clásico, es cuando los clientes ponen formularios de registro tremendamente extensos, que luego son costosos de administrar, y que se vuelven una carga durante todo el proceso de desarrollo cuando quieren volver atrás y cambiar ese formato por uno nuevo, generando un montón de errores de arrastre en el proceso.
un caso sencillo seria simlpe login donde hay que validar que el campo de usuario y cotnrasena no esten vacios y sean caracteres aceptables para ambos campos que podamos ver esos campos que tengamos el boton de login
Lo clásico es que le pasa al sistema cuando algo no existe, digamos si hacemos omelette con espinaca pero no hay huevos. Siempre es necesario probar esos edge cases que nadie se espera
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?