En este artículo se escriben las ventajas del TDD en cuanto a Mejora de calidad, simplicidad de diseño y mejora de productividad.
Asimismo, se describen algunos problemas y sus posibles soluciones, tales como: Problemas con obtejos de interfaz gráfica, base de datos, posibles errores no identificados y perdidas de la visión general de la arquitectura de software.
Presentamos a continuación las ventajas y desventajas del Test Driven Development (TDD):
Ventajas del TDD
1.- Mayor calidad
Garantiza que las pruebas se ejecutan (no sean omitidas), evitando que las aplicaciones tengan fallas la primera vez que el usuario las ejecuta o que el usuario encuentre los errores, en lugar de ser encontrados por el equipo de desarrollo.
Asimismo, el hacer pruebas en etapas tempranas del desarrollo es una forma de incorporar la calidad al proceso, resultando en menos errores (bugs) en las etapas finales del proyecto.
2.- Diseño enfocado en las necesidades
El escribir las pruebas primero que el código, obliga a que las necesidades reales del cliente sean consideradas primero, obligando a analizar primero qué es lo que realmente se necesita que el código haga y no al contrario. Como resultado, habrá menos retrabajo después.
3.- Mayor simplicidad en el diseño
Bajo TDD, en lugar de enfocarse en realizar diseños extensos y complejos, el equipo se enfocará en la necesidad o requerimiento del cliente, agregando solamente la funcionalidad que el cliente necesita. Esto es muy importante, pues es la complejidad la que produce los errores.
Esto obliga a escribir código enfocado en las necesidades del usuario, evitando antipatrones como los objetos multipropósito (clase gorda) o el acoplamiento del código, dado que desarrollarán códigos específicos a los requerimientos que se estén atendiendo en esa iteración.
4.- El diseño se va adaptando al entendimiento del problema
A medida que se realizan iteraciones de probar y programar, el entendimiento del problema se incrementa, de esta forma, sucesivas iteraciones cuentan con un mayor entendimiento, lo que reduce los malos entendidos de la funcionalidad al final del desarrollo, resultando en menos retrabajo.
5.- Mayor productividad
En un proyecto tradicional, generalmente lo que sucede es que al principio se es muy productivo, sin embargo, esa productividad cae hacia el final del proyecto, cuando empiezan a encontrarse errores en todas partes, se encuentran malentendidos en lo que el cliente quería, o cuando el cliente hace un par de cambios desestabilizadores.
En contraposición a este esquema, una de las principales ventajas de TDD es que se obtiene retroalimentación (feedback) inmediato sobre el software desarrollado.
Trabajando bajo TDD, al principio se algo improductivo, pues se necesita escribir una serie de casos de prueba que fallaran al primer intento, sin embargo, los beneficios se hacen evidentes cuando se ha probado constantemente la aplicación, se han corregido los errores de forma temprana y de han aclarado de forma temprana las dudas en la funcionalidad.
6.- Menos tiempo invertido en debugging de errores
El código se va desarrollando por piezas pequeñas, por ende, cuando surge un error, los esfuerzos se enfocan en la pequeña pieza de código que fue modificada, por lo que se le pueden llegar a los problemas de forma más directa.
Posibles problemas del TDD y sus soluciones
1.- Interfaz de usuario
TDD es difícil de implementar en la capa de interfaz de usuario (presentación), debido a que está actividad contiene elementos que contienen a alargar el ciclo de prueba y desarrollo. En su lugar, TDD encaja más fácilmente en los desarrollos en las capas de lógica de negocios (objetos y dominio) y acceso a datos. Por ende, pueden existir reservas respecto a aplicar TDD en una aplicación con alto grado de interacción con el usuario.
Sin embargo, esto no es necesariamente algo malo, dado que la metodología obliga a separar las capas y a no implementar lógica de negocio en la capa de presentación, lo cual sería un anti patrón.
2.- La Base de datos
Uno de los principales problemas de usar TDD en aplicaciones con bases de datos, es que una vez que se ha ejecutado una prueba, la base de datos puede quedar en un estado distinto al que se necesita para hacer la siguiente prueba (por ejemplo, si la aplicación necesita cambiar el valor de un campo de A a B, cuando la prueba termina el valor queda en B, por lo que no se puede ejecutar una siguiente prueba).
Una forma de abordar este problema es escribir código para inicializar la base de datos en el estado previo, sin embargo esto añade carga de trabajo adicional.
Otra solución es utilizar objetos para representar la base de datos, por medio de objetos cascaron, respuestas predefinidas o dummies que emulen las respuestas de la base de datos.
3.- Errores no identificados
Sólo por el hecho de pasar todas las pruebas en la herramienta que se utilize (JUNIT por ejemplo), no significa que no se tengan errores, sólo significa que las pruebas que se han ejecutando no han encontrado errores. El utilizar TDD podría llevar a un falso sentimiento de seguridad, por ende, se necesita enfocarse en que las pruebas sean detalladas y cubran todos los escenarios posibles.
4.- Perder la visión general (Ver el árbol en lugar del bosque)
TDD es un enfoque de abajo hacia arriba (Bottom-Up), y se debe estar al tanto que podría perderse visibilidad general del proyecto y del aplicativo. Es una buena idea mantener un modelo general (bajo un enfoque tradicional como UML) y revisarlo de vez en cuanto, quizás se encuentren oportunidades para refactorizar y hacer que la aplicación se le pueda dar mantenimiento en el tiempo.
5.- Pronunciada curva de aprendizaje
Como se ha dicho en otras entregas, TDD es difícil de adoptar, por lo que puede esperarse un descenso en la productividad durante los primeros dos meses de implementación. Lo recomendable para enfrentar esto es buscar ayuda, por medio de formación (cursos) y consultorías que apoyen en la adopción de la nueva forma de trabajo.
¿Y tú?, ¿Qué opinas?
Queremos escuchar tu opinión sobre el Test Driven Development, ¿Has encontrado ventajas?, ¿Has encontrado desventajas?, ¿Qué aspectos de los métodos ágiles has puesto en práctica?, ¿Cuáles fueron los resultados?.
<< Artículo anterior: TDD 9 retos para su implementación
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia de proyectos y metodologías ágiles?, entonces presiona "suscríbete" a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Referencia:
Levison, M. Adavantages of TDD. Del Blog: Agile Pain Relief
Otros artículos de TDD
¿Desea obtener más información sobre TDD?, le invitamos a visitar también los siguientes artículos en el Blog “La Oficina de Proyectos de Informática”.
>> Test Driven Development (TDD): 9 retos para su implementación y cómo hacerles frente
>> Test Driven Development (TDD): Desarrollo de software guiado por pruebas
6.- Menos tiempo invertido en debugging de errores
El código se va desarrollando por piezas pequeñas, por ende, cuando surge un error, los esfuerzos se enfocan en la pequeña pieza de código que fue modificada, por lo que se le pueden llegar a los problemas de forma más directa.
Posibles problemas del TDD y sus soluciones
1.- Interfaz de usuario
TDD es difícil de implementar en la capa de interfaz de usuario (presentación), debido a que está actividad contiene elementos que contienen a alargar el ciclo de prueba y desarrollo. En su lugar, TDD encaja más fácilmente en los desarrollos en las capas de lógica de negocios (objetos y dominio) y acceso a datos. Por ende, pueden existir reservas respecto a aplicar TDD en una aplicación con alto grado de interacción con el usuario.
Sin embargo, esto no es necesariamente algo malo, dado que la metodología obliga a separar las capas y a no implementar lógica de negocio en la capa de presentación, lo cual sería un anti patrón.
2.- La Base de datos
Uno de los principales problemas de usar TDD en aplicaciones con bases de datos, es que una vez que se ha ejecutado una prueba, la base de datos puede quedar en un estado distinto al que se necesita para hacer la siguiente prueba (por ejemplo, si la aplicación necesita cambiar el valor de un campo de A a B, cuando la prueba termina el valor queda en B, por lo que no se puede ejecutar una siguiente prueba).
Una forma de abordar este problema es escribir código para inicializar la base de datos en el estado previo, sin embargo esto añade carga de trabajo adicional.
Otra solución es utilizar objetos para representar la base de datos, por medio de objetos cascaron, respuestas predefinidas o dummies que emulen las respuestas de la base de datos.
3.- Errores no identificados
Sólo por el hecho de pasar todas las pruebas en la herramienta que se utilize (JUNIT por ejemplo), no significa que no se tengan errores, sólo significa que las pruebas que se han ejecutando no han encontrado errores. El utilizar TDD podría llevar a un falso sentimiento de seguridad, por ende, se necesita enfocarse en que las pruebas sean detalladas y cubran todos los escenarios posibles.
4.- Perder la visión general (Ver el árbol en lugar del bosque)
TDD es un enfoque de abajo hacia arriba (Bottom-Up), y se debe estar al tanto que podría perderse visibilidad general del proyecto y del aplicativo. Es una buena idea mantener un modelo general (bajo un enfoque tradicional como UML) y revisarlo de vez en cuanto, quizás se encuentren oportunidades para refactorizar y hacer que la aplicación se le pueda dar mantenimiento en el tiempo.
5.- Pronunciada curva de aprendizaje
Como se ha dicho en otras entregas, TDD es difícil de adoptar, por lo que puede esperarse un descenso en la productividad durante los primeros dos meses de implementación. Lo recomendable para enfrentar esto es buscar ayuda, por medio de formación (cursos) y consultorías que apoyen en la adopción de la nueva forma de trabajo.
¿Y tú?, ¿Qué opinas?
Queremos escuchar tu opinión sobre el Test Driven Development, ¿Has encontrado ventajas?, ¿Has encontrado desventajas?, ¿Qué aspectos de los métodos ágiles has puesto en práctica?, ¿Cuáles fueron los resultados?.
<< Artículo anterior: TDD 9 retos para su implementación
>> Siguiente Artículo: TDD Como llevarlo a la práctica
¿Buscas más información de metodologías ágiles?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia de proyectos y metodologías ágiles?, entonces presiona "suscríbete" a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Lectura recomendada
Proyectos Ágiles con Scrum: Flexibilidad, aprendizaje, innovación y colaboración en contextos complejos
Autor: Martin Alaimo; Martin Salas.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
>> Ver reseña
En este libro encontrarás un excelente compendio de las metodologías ágiles, sus procedimientos y artefactos. Excelentes ejemplos prácticos.
Autor: Martin Alaimo; Martin Salas.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
>> Ver reseña
En este libro encontrarás un excelente compendio de las metodologías ágiles, sus procedimientos y artefactos. Excelentes ejemplos prácticos.
Gestión práctica de proyectos con Scrum: Desarrollo de software ágil para el Scrum Master
Autor: Antonio Martel.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
Una gran cantidad de casos reales y experiencia práctica para el Scrum Master en los proyectos con metodologías ágiles, como hacer estimaciones, presupuestos, lecciones aprendidas y más.
Autor: Antonio Martel.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
Una gran cantidad de casos reales y experiencia práctica para el Scrum Master en los proyectos con metodologías ágiles, como hacer estimaciones, presupuestos, lecciones aprendidas y más.
¿Interesado en otros productos y últimas novedades?
>> Visita nuestra sección de productos amazon
>> Visita nuestra sección de productos amazon
Referencia:
Levison, M. Adavantages of TDD. Del Blog: Agile Pain Relief
Otros artículos de TDD
¿Desea obtener más información sobre TDD?, le invitamos a visitar también los siguientes artículos en el Blog “La Oficina de Proyectos de Informática”.
>> Test Driven Development (TDD): 9 retos para su implementación y cómo hacerles frente
>> Test Driven Development (TDD): Desarrollo de software guiado por pruebas
Otros artículos sobre metodologías ágiles
>> Los 5 valores de la programación extrema
>> 5 Preguntas y respuestas sobre el Feature Driven Development (FDD)
>> Plantillas Scrum: historias de usuario y criterios de aceptación
>> Scrum de Scrum: Desarrollo ágil para grandes proyectos
>> 5 métricas de desempeño para proyectos de desarrollo ágil y Scrum
>> Herramientas de software para gestión de proyectos de desarrollo ágil
>> El Desarrollo ágil en un entorno de fechas y presupuestos predefinidos
>> Los Programas de Certificación del Scrum Alliance
>> Preguntas y respuestas sobre Scrum Alliance
>> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?
>> Metodologías de desarrollo ágil
>> Los 5 valores de la programación extrema
>> 5 Preguntas y respuestas sobre el Feature Driven Development (FDD)
>> Plantillas Scrum: historias de usuario y criterios de aceptación
>> Scrum de Scrum: Desarrollo ágil para grandes proyectos
>> 5 métricas de desempeño para proyectos de desarrollo ágil y Scrum
>> Herramientas de software para gestión de proyectos de desarrollo ágil
>> El Desarrollo ágil en un entorno de fechas y presupuestos predefinidos
>> Los Programas de Certificación del Scrum Alliance
>> Preguntas y respuestas sobre Scrum Alliance
>> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?
>> Metodologías de desarrollo ágil
No hay comentarios :
Publicar un comentario