Al realizar desarrollos de gran envergadura, muchas veces perdemos de vista cuando hacemos un cambio en que va a afectar al resto del mismo, este tipo de incertidumbres pueden desembocar en catástrofe si realmente los nuevos cambios dañan algo que ya estaba aprobado previamente.
Para evitar este tipo de situaciones es que se hace el desarrollo basado en pruebas, es decir, que construimos las pruebas del sistema antes de construir el código con la solución, de esta forma empezamos con algo que nos da fallas desde un principio y vamos haciendo que pase todas las pruebas.
Cuando agregamos un nuevo cambio simplemente corremos todas las pruebas ya escritas y si alguna que ya había pasado falla sabemos que debemos hacer una corrección en nuestro código.
Prueba primero, codifica luego
En el enfoque de programación, usualmente lo que hacemos es escribir una pieza de código y luego probar nuestro programa a ver si corre y nos da el resultado esperado, muchos podrían decir que esto es lo mejor y tal vez para ciertos requerimientos sea la mejor opción, pero que pasa si con cada código nuevo debemos probar todo un proceso de compras, donde pasamos 15 minutos solo probando, esto sería mucha perdida de tiempo que podríamos pasar realizando otras actividades de nuestro proyecto.
En la programación extrema donde debemos conseguir con el mínimo de recursos y tiempo grandes resultados, si nos imaginamos la situación anterior nos estamos garantizando un fracaso seguro, aquí es donde entra la programación basada en pruebas o Test Driven Development como muchas veces lo encontraremos, con esto primero haremos la prueba y luego el código, obligándonos a tener un soporte con la prueba y así tener la certeza que nuestro código no falla, entonces al final en vez de probar un proceso de compras simplemente correremos un archivo que nos dará el resultado de los checkpoints que decidamos probar.
Veamos a continuación una imagen con un código que realiza unas pruebas y luego explicaremos su funcionamiento:
En el código empezamos haciendo un import del método rect_area, asignamos unos valores y establecemos la respuesta adecuada, luego con un condicional vemos si esta respuesta corresponde con el llamado al método indicado.
Si es correcto imprimimos que pasamos la prueba, de lo contrario la prueba ha fallado, este enfoque bastante simple de lo que es una prueba nos demuestra que más que ver si nuestro programa corre o no, estamos es buscando una validación sobre nuestra solución a nivel general, ya que al saber lo que debemos retornar conocemos el problema y con ello debemos conseguir la forma de resolverlo.
En la prueba de ejemplo si la corremos debemos tener muchos errores al principio al ir resolviendo cada uno de ellos vamos logrando la validación de nuestra solución.
Aunque al principio parezca que estamos programando al revés, al final del día esta metodología nos puede ahorrar muchos dolores de cabeza cuando estamos haciendo un sistema grande y complejo.
Para evitar este tipo de situaciones es que se hace el desarrollo basado en pruebas, es decir, que construimos las pruebas del sistema antes de construir el código con la solución, de esta forma empezamos con algo que nos da fallas desde un principio y vamos haciendo que pase todas las pruebas.
Cuando agregamos un nuevo cambio simplemente corremos todas las pruebas ya escritas y si alguna que ya había pasado falla sabemos que debemos hacer una corrección en nuestro código.
Prueba primero, codifica luego
En el enfoque de programación, usualmente lo que hacemos es escribir una pieza de código y luego probar nuestro programa a ver si corre y nos da el resultado esperado, muchos podrían decir que esto es lo mejor y tal vez para ciertos requerimientos sea la mejor opción, pero que pasa si con cada código nuevo debemos probar todo un proceso de compras, donde pasamos 15 minutos solo probando, esto sería mucha perdida de tiempo que podríamos pasar realizando otras actividades de nuestro proyecto.
En la programación extrema donde debemos conseguir con el mínimo de recursos y tiempo grandes resultados, si nos imaginamos la situación anterior nos estamos garantizando un fracaso seguro, aquí es donde entra la programación basada en pruebas o Test Driven Development como muchas veces lo encontraremos, con esto primero haremos la prueba y luego el código, obligándonos a tener un soporte con la prueba y así tener la certeza que nuestro código no falla, entonces al final en vez de probar un proceso de compras simplemente correremos un archivo que nos dará el resultado de los checkpoints que decidamos probar.
Veamos a continuación una imagen con un código que realiza unas pruebas y luego explicaremos su funcionamiento:
En el código empezamos haciendo un import del método rect_area, asignamos unos valores y establecemos la respuesta adecuada, luego con un condicional vemos si esta respuesta corresponde con el llamado al método indicado.
Si es correcto imprimimos que pasamos la prueba, de lo contrario la prueba ha fallado, este enfoque bastante simple de lo que es una prueba nos demuestra que más que ver si nuestro programa corre o no, estamos es buscando una validación sobre nuestra solución a nivel general, ya que al saber lo que debemos retornar conocemos el problema y con ello debemos conseguir la forma de resolverlo.
En la prueba de ejemplo si la corremos debemos tener muchos errores al principio al ir resolviendo cada uno de ellos vamos logrando la validación de nuestra solución.
Aunque al principio parezca que estamos programando al revés, al final del día esta metodología nos puede ahorrar muchos dolores de cabeza cuando estamos haciendo un sistema grande y complejo.
