Primero hablemos sobre el desarrollo comenzando por las pruebas, éstas acarrean algunas ventajas, tanto de orden técnico como metodológico. Aquí algunos ejemplos:
Al escribir antes las pruebas, las mismas se convierten en especificaciones de lo que se espera como respuesta del objeto ante el envió de un determinado mensaje. Por lo tanto, no se debería codificar nada que no tenga su prueba de antemano, de modo tal de no implementar nada innecesario.
Al ir definiendo de a una prueba a la vez, tenemos un desarrollo incremental genuino, definido por pequeños incrementos que se corresponden con funcionalidades muy acotadas.
Permiten independizarse del factor humano, con su carga de subjetividad y variabilidad en el tiempo haciendo que sean mas optimas y precisas.
Al necesitar éstas un costo muy bajo para poder ser ejecutadas, generan que el programador genere un hábito de testear y a su vez le de cierta confianza en que su código esté correcto o pase la prueba.
Y el TDD? Ahí va...
Ésta forma de trabajar fue propuesta formalmente por el señor Kent Beck donde habló sobre una práctica de desarrollo denominada Test-Driven-Development.
Ésta práctica nos obliga a pensar a través de la interfaz necesaria antes de desarrollar
Según Beck TDD incluye tres practicas fundamentales:
- Test-First: Escribir las pruebas antes del código.
- Automatización: Las prubas deben correr con la mínima intervención humana.
- Refactorización.
Muy lindo hasta ahora pero, cuales son los pasos para aplicar TDD?
Pasos para aplicar TDD
- Escribir el test, el cual no pasará.
- Agregar el mínimo código posible para que la prueba pase.
- Refactorizar.
Fácil no? Claro que si!.
De esta manera el desarrollador podrá avanzar de manera mas lenta pero segura... siempre hay que tener en cuenta hacer baby steps.
Partes del post fue obtenido del libro del Profesor
Carlos Fontela de la Facultad de Ingeniería de la Universidad de Buenos Aires.
Top comments (0)