Cada nuevo proyecto involucra el tener que interactuar con nuevos grupos de trabajo, nuevas personas y nuevos retos, pero recientemente algo que me ha llamado mucho la atención es el hecho de que varias personas dicen conocer acerca de ciertas metodologías de desarrollo de software, no es que yo me considere una eminencia en todas las materias, pero si cuando no tengo mucha idea sobre un tema, primero escucho y después investigo de que trata.
Volviendo al inicio (“bottom line”), en una reciente plática con un equipo de trabajo, se estaba discutiendo el tema de las pruebas unitarias y el cómo se van a emplear en el proyecto, algunos mencionaron que nunca las habían empleado, otros habían solo leído o escuchado sobre de ellas y otros decían que tenían amplia experiencia y que incluso habían aplicado TDD (Test-Driven Development)…interesante punto!
Cuando les pedía a los que “habían” empleado TDD comentarán sobre sus experiencias y utilidad, surgieron los siguientes puntos:
- Comentaban que su tiempo de implementación alargaba en tiempo de desarrollo del proyecto.
- Que se hacía complicado cumplir con las coberturas de código.
- Al final terminaban haciendo muchas pruebas unitarias.
- Que el IDE ya generaba automáticamente las pruebas y aplicaba el TDD…..?
Después de escuchar los comentarios no pude evitar comentar: hacer pruebas unitarias NO es aplicar TDD!, decirle a un Wizard que tome nuestros componente y automáticamente genere las pruebas unitarias NO es TDD!. Muchas veces no se logran comprender los verdaderos beneficios (o desventajas) de aplicar tal o cual práctica ó nos mal acostumbramos al flujo de trabajo que sigue cierta herramienta y creemos que así es como esta se aplica (todo gracias a la mercadotecnia!).
TDD es una práctica que se encuentra enfocada en aplicar dos principios básicos: Escribir primero las pruebas unitarias y Refactoring de código. Para la definición de las pruebas unitarias se requiere tener claramente definidos los requerimientos (punto importante!), y una vez que se tengan claros aplicar los siguientes puntos:
a) Tomar un requerimiento (con su respectivo caso de uso) que sea factible de iniciar su implementación o que sea más representativo.
b) Definir la prueba unitaria con un nombre que describe el requerimiento.
Ejemplo: IniciarSesiónConTokenDeSeguridadTest().
c) Verificar que la prueba falla, se supone que en un principio esta se encuentra vacía y no tiene código.
d) Implementar la prueba unitaria, es decir empezar a codificar a fin de realizar la implementación que cumpla con el propósito de la prueba unitaria.
e) Ejecutar la prueba unitaria y verificar que funcione.
f) Aplicar refactoring del código a fin de eliminar redundancias y reducir la implementación.
g) Opcionalmente detectar posibles comportamientos que no se encontraban claramente especificados en el requerimiento implementado.
Revisando los puntos anteriores, el uso de este tipo de prácticas permite reducir la cantidad de errores y principalmente, permite al desarrollador confiar en su código al momento de la implementación de las pruebas unitarias, además de que las pruebas permiten mostrar el avance del trabajo y poder demostrar escenarios de comportamiento que nuestros usuarios puedan revisar de forma simple.
Como toda práctica tiene sus ventajas y desventajas, por lo que su uso debe de estar condicionado a la experiencia de quienes lo van a implementar y se encuentren a gusto con trabajar de este modo. En mi caso lo he aplicado y me ha funcionado bastante bien, pero como siempre en gustos (y prácticas) se rompen géneros!
Geek, Software, Tips & Tricks | Heinsk | 
December 10, 2009 3:09 am | 
Comments (0) 
Subscribe