COMO DEBERÍA SER EL DESARROLLO: TDD Y/O BDD. UNA SIGNIFICATIVA INTRODUCCIÓN

< script src=”other pages” title=”como debería ser el desarrollo: tdd y bdd” >

Cuando dicen: “vamos a implementar pruebas automatizadas”, es como así (y tal vez peor):

Y es que para nosotros, los desarrolladores nuevos recién salidos del horno universitario que venimos del Pascal, con suerte del Java y de la dupla C/C++ (Borland C/C++ en mi caso 😥 ), y dependiendo de la “¿experiencia?”, del PHP y del MySQL (pre-Oracle, claro 😡 ), que “ahora” se piense en TDD (a.k.a. Desarrollo Orientado por Pruebas o Test-Driven Development si les gusta el inglés) es como para quedarse como la ardilla del video (yo lo hice ^^’ ).

TDD no es un concepto nuevo, la verdad, según Javier Garzás es bastante anciano (el concepto de TDD, no Javier jijiji 😳 ), pero como más sabe el diablo, por viejo que por diablo, vaya Dios a saber a quién se le ocurrió la idea de sacar la naftalina del TDD y refrescarla para estos días. ¡Ah, si, ya me acordé! Kent Beck, por allá en el 2008 🙂 .

Básicamente, en TDD, las pruebas se escriben primero, antes que el código. Ya pensar así representa algunas barreras para los programadores nóveles (como yo) que quieren escribir código a la primera jejeje 😎 , y como toda metodología tiene una serie de pasos y de principios a seguir para llevar a buen término un TDD:

El mantra del TDD

El mantra del TDD 🙄

Me explico, para que cada prueba tenga impacto sobre el código que se escribe, debe pasar las siguientes etapas:

RED: ESCRIBE UNA PRUEBA QUE FALLE

Digamos que tienes un requisito funcional bien especificado, entonces la idea es escribir la prueba que satisfaga ese requisito. Eventualmente, la prueba fallará, puesto que no hemos escrito código alguno para comprobar si la funcionalidad descrita en el requisito es realmente lo que se espera en el software que se está desarrollando, además de considerar que se debe escribir una sola prueba por funcionalidad. Esta prueba debe respetar el principio KISS XD .

GREEN: ESCRIBE CÓDIGO QUE PASE LA PRUEBA

Ejecutamos la prueba (en el lenguaje de tu preferencia o de preferencia del cliente, dejémoslo así 😐 ), ¡y falla! Eso es lo que queremos acá, porque ahora debemos pensar: ¿que cosas satisfacen la prueba? Si la prueba es que, por ejemplo, debe sumar dos números y dar un resultado particular, pues ya tienes dos elementos importantes: los números y el resultado, amén de otros elementos de forma del código que cumplan con el principio SOLID XD .

REFACTOR: ESCRIBE OPTIMIZACIONES PARA TU CÓDIGO

En el proceso bidireccional de escribir pruebas para el código y viceversa, siempre existe una forma más óptima de hacerlo, acá la idea es más bien, darle un poco de calidad al código. A ver, siempre habrá más de una forma de pensar en como pasar las pruebas, sin embargo, sucede que nos quedamos con la primera por lo reducido de los tiempos de entrega, entre otras cosas que impiden que tu código respete el DRY XD , y todo se te vuelve un copy-paste.

Por ahora no pretendo ahondar en muchos conceptos respecto a este tema, mucho menos en código (eso lo voy a dejar para posts siguientes 😈 *risa malvada*) , pero si dejar en claro que ninguna herramienta, metodología o tecnología es la Panacea que va a resolver todos tus problemas en desarrollo de software, hace falta “probar” 😉

</script>

Anuncios

Un comentario en “COMO DEBERÍA SER EL DESARROLLO: TDD Y/O BDD. UNA SIGNIFICATIVA INTRODUCCIÓN

Los comentarios están cerrados.