El desarrollo guiado por pruebas (test-driven development), o TDD, es una de las principales prácticas de Extreme Programming (XP), que propone una serie de pasos para probar antes de programar (test-first programming).
El proceso a realizarse es el siguiente:
• Se crea un caso de prueba que verifica una pequeña funcionalidad del sistema.
• Se ejecuta el caso de prueba, y deberá tener un resultado NO exitoso, ya que la funcionalidad que intenta probar aún no está construida.
• Una vez que se observa el fallo, se desarrolla únicamente el código que hará que la prueba sea exitosa.
• Por último, se hace un refactoring del código para asegurar que se tiene el diseño más simple para la funcionalidad que acaba de agregarse.
Una vez que estos pasos son llevados a cabo, se realiza lo que motiva a la metodología: la ejecución de todas las pruebas automatizadas que se tienen construidas hasta el momento.
Podemos visualizar gráficamente el párrafo anterior en el siguiente diagrama de actividad en UML.
Luego de esta breve explicación que sólo intenta inducir a los desconocedores e introducir a los entendidos, se pueden vislumbrar cuáles podrían ser las ventajas y las desventajas de utilizar dicha metodología.
Ventajas
• Requerimientos de última hora. ¿Cuántas veces un requerimiento introducido a último momento le causó defectos en producción debido a un error en el análisis de impacto? ¿En cuál de las siguientes situaciones preferiría estar si necesita cambiar un sistema en producción?
a) Cualquiera sea el cambio que usted realice su forma de trabajo le permite probar su impacto en todo el sistema en minutos.
b) Alcanza a realizar los cambios pero no tiene tiempo para probar, entonces debe liberar y cruzar los dedos para que funcione y no afecte otras partes del sistema.
• Se desarrollan 100% de las pruebas. Todas las pruebas se realizan de manera automática y no existe el escenario en que no se puede completar la creación de los casos de prueba debido a que no se escribe una línea de código que no corresponda a un caso de prueba automatizado.
• Cobertura de requerimientos al 100%. Debido a que los requerimientos son expresados en forma de casos de prueba y dichos casos son ejecutados automáticamente, cada vez que se agrega una funcionalidad al sistema, estamos seguros de que al finalizar nuestro desarrollo habremos cubierto en 100% los requerimientos del mismo, debido a que ninguno de nuestros casos de prueba ha fallado.
Desventajas
• El éxito depende de los casos de prueba. Si se hizo una interpretación incorrecta de un requerimiento, se escribirá un caso de prueba que no satisfaga a los deseos del usuario, por lo tanto el producto final será incorrecto.
• Interfaces gráficas. Si se hace el intento de probar las interfaces gráficas y estas cambian, debemos perder tiempo en adaptar nuestras pruebas automatizadas. Esto podría causar que en cada versión se invierta tanto tiempo en reescribir las pruebas que se opte por no hacerlo.
Complementando la Metodología
Después de involucrarme un tiempo con la metodología de desarrollo guiado por pruebas y de disfrutar sus virtudes y sufrir sus defectos, he aprendido a resolver estas limitantes a través del uso de un par de herramientas de IBM-Rational. A continuación les comparto más al respecto.
Problema 1: Interfaces Gráficas
La herramienta Functional Tester de IBM-Rational cuenta con una tecnología llamada ScriptAssure la cual utiliza algoritmos configurables para localizar a los objetos durante la ejecución de las pruebas, aunque éstos hayan cambiado desde la creación del caso de prueba inicial. Es así que Functional Tester actualiza de manera inteligente la forma en que reconoce a los objetos en Java, aplicaciones Web y .NET sin intervención humana, por lo que no requiere que se actualicen los scripts cada vez que cambia la aplicación.
Las herramientas que no cuenten con una tecnología semejante a la descrita, no lograrán reconocer la casilla de verificación y requerirán que el desarrollador reprograme sus pruebas. Si esto ocurre en una simple ventana de login como la del ejemplo, ¿qué sucederá con aplicaciones complejas como en las que usted trabaja? Será tanto el trabajo de mantenimiento de los scripts de prueba que sus programadores dejarán de ser productivos.
Otras virtudes que encontré en esta herramienta y que afirmaron mi decisión de adoptarla son:
• Los scripts de prueba se pueden programar en Visual Basic .Net y Java.
• Tiene herramientas de depuración incluidas en el ambiente de desarrollo tanto para VB .Net como para Java.
• Incluye la posibilidad de incluir pruebas manejadas por datos
• Soporta la introducción de expresiones regulares para el manejo de patrones.
• Tiene un agregado para soportar aplicaciones para terminales 3270 y 5250.
• Soporta pruebas automatizadas para ambientes Siebel 7.7.
Problema 2: El éxito Depende de los Casos de Prueba
Para evitar el problema de tener casos de prueba que no concuerden con los requerimientos, lo que podemos hacer es que sean los mismos analistas de negocio quienes desarrollen los casos de prueba. Para esto, no necesitan tener conocimientos técnicos ni desarrollar scripts. Simplemente utilizan otra herramienta de IBM-Rational denominada Manual Tester, y en ella definen fácilmente los casos de prueba.
Para especificar un caso de prueba, simplemente se define la serie de pasos a seguir, y se especifican valores de entrada, así como el resultado(s) esperado. Posteriormente, los desarrolladores se basan en estos casos de prueba capturados en el Manual Tester, para generar los scripts para pruebas automatizadas. Este procedimiento para generar los scripts está metodológicamente explicado y no da lugar a errores u omisiones.
Algunos beneficios adicionales de capturar los casos de prueba con el Manual Tester son:
• Proporciona la posibilidad de colocar imágenes para complementar los pasos y contribuir a eliminar ambigüedad.
• Permite la reutilización de patrones de prueba en diferentes pruebas.
• Incluye ingreso y verificación de datos asistido durante la ejecución de las pruebas para reducir el error humano.
Conclusión
Más allá de las herramientas, es importante que se entienda el concepto que está detrás de todo esto. El principal objetivo es lograr que los casos de prueba automatizados, que son la clave del éxito del desarrollo dirigido por pruebas, no partan de una mala interpretación de los requerimientos. El segundo y, no mucho menos importante, es encontrar la manera de que los programadores no dejen de ser productivos por tener que escribir casos de prueba automatizados para cada funcionalidad antes de desarrollar. Este artículo resalta estas dos cuestiones y dando un ejemplo de cómo resolverlas con un par de herramientas en particular. Pero no es necesario que se limiten a éstas. Los invito a que exploren las diferentes herramientas para pruebas automatizadas disponibles en el mercado, y tal como yo lo hice arriben a la solución técnica que más les acomode, sin perder de vista los objetivos propuestos.
Acerca del autor Ariel Súcari es consultor de It Era especializado en pruebas de software. Graduado de la Universidad CAECE en Buenos Aires, Argentina. Ha participado y coordinado proyectos de la disciplina de pruebas en Inglaterra, Estados Unidos, Venezuela, Argentina y México durante los últimos 7 años.
- Log in to post comments