TDD: Componentes difíciles de probar - La Oficina de Proyectos de Informática

lunes, 24 de diciembre de 2012

TDD: Componentes difíciles de probar


Un factor crítico de éxito del Test Driven Development (TDD) es la automatización de pruebas unitarias, pues son estas las que permiten los ciclos de iteraciones rápidas, necesarios para aplicar de forma éxitosa la práctica TDD.

Sin embargo, se presentar dificultades cuando deben probarse componentes externos al software que se está desarrollando.

En este artículo se describen cuales son las áreas que tienen a presentar problemas, como por ejemplo bases de datos y la interfaz gráfica.

Asimismo, presenta un enfoque para enfrentar este reto, por medio de la abstracción y aislamiento de los segmentos de código difíciles de probar.

Presentamos a continuación las áreas difíciles de probar y el porqué:

Curso Online de Scrum Master


¿Te gustaría obtener una visión general y completa de Scrum y despejar falsos paradigmas? 

Inscríbete en el Curso: 


Bases de datos

Un componente de software que contenga llamadas a bases de datos tiende a presentar problemas a la hora de probarlo de forma automatizada, debido a:

  • Las llamadas a base de datos pueden ser de ejecución lenta, lo cual alarga la duración de la prueba. Cuando estas se ejecutan repetidamente puede tener impacto.
  • Por lo general, cuando se presenta un error de ejecución en base de datos, la solución implica a varios componentes (no necesariamente sólo el que se está probando). La causa raíz de los errores es difícil de identificar, alargando la duración de la prueba. Al igual que en el punto anterior puede tener impacto, pues en TDD las pruebas se ejecutan muchas veces.
  • Para que la prueba pueda automatizarse, es necesario agregar instrucciones para inicializar los datos y luego para regresarlos a su estado original, esto implica tener que agregar código adicional no relacionado con la prueba en sí, incrementando la complejidad de la prueba.
  • Muchas veces no se está seguro de lo que retornará la base de datos, pues es un componente externo, quizás hasta desarrollado previamente en otro proyecto y por otro equipo. Por ende, se requiere agregar lógica condicional para revisar que lo retornado por la base de datos está bien.

Interfaz Gráfica

Los componentes de interfaz gráfica (por ejemplo una pantalla), son más difíciles de probar por medios automatizados que métodos o clases, debido a:

  • La gran mayoría de las herramientas de automatización de pruebas unitarias tienden a presentar dificultades y resultados impredecibles cuando existen componentes de interfaz gráfica involucrados.
  • Ejecución lenta: La lentitud viene porque las prueba implica las capas de lógica de negocio y base de datos. Esto rompe con el ciclo de ejecuciones e iteraciones rápidas, necesario en TDD.
  • Fragilidad: Cualquier cambio o refactorización puede ocasionar que la prueba automatizada de interfaz gráfica deje de funcionar. Esta fragilidad ocasiona altos esfuerzos en el mantenimiento de las pruebas automatizadas.

Otros componentes con posibles problemas

  • Componentes que requieran comunicaciones entre distintas redes.
  • Interacciones con el sistema de archivos.
  • Pruebas que requieren una configuración previa del ambiente.
  • Llamadas a procesos externos (incluyendo a la base de datos).

Posibles soluciones

La solución consiste en agrupar las cosas que sean realmente difíciles de probar y empaquetarlas detrás de interfaces o abstracciones, para luego separar otros códigos y funcionalidad del segmento de código que sea difícil de probar. Esto implica separar códigos que acceden a sistemas externos, interfaz gráfica o cualquier cosa que implique un Web Service.

No es casual que una de las soluciones está en la aplicación adecuada del patrón de modelo vista presentador (MVP). El código de presentación (Interfaz gráfica, interfaz web, formas) son difíciles de probar, por ende, la solución es colocar la menor cantidad de código posible en esa área. Por ejemplo, la lógica de flujo entre las pantallas se puede colocar en clases separadas de los componentes de vista. Utilizando este esquema, se simplifica la lógica de código que controla el flujo de interfaz gráfica.

Por medio de este esquema es posible probar la interfaz gráfica por separado de la lógica que controla el flujo de navegación.

Otro ejemplo es colocar el código de acceso a un componente externo en una clase separada, por ejemplo, si se requiere acceder a Consultas de Active Directory como parte de un proceso de autorización, se puede colocar todas estas instrucciones en una clase, pudiendo de esta forma probar el resto de la lógica de la autorización sin involucrarlos.

La clave en evitar las áreas difíciles y producir código más fácil de probar está en aprender cómo dividir las responsabilidades entre las clases.

Próximas entregas

En próximas entregas de la serie de TDD, se describirá el concepto de Refactoring, el cual es esencial en la Programación Extrema (XP) y en Test Driven Development.

¿Y tu? ¿Que opinas?

¿Que opinas sobre la dificultad de probar de forma automatizada áreas como la Base de datos o interfaz gráfica?, ¿Como superarías estas dificultades?,¿ Que otras áreas consideras que son difíciles de probar al aplicar una práctica como el TDD?.

¿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.

Suscríbete a la lista de correo electrónico:


Vía FeedBurner, se abrirá una nueva ventana

Tambíen puedes seguirnos al Twitter @PMOInformatica o página de Facebook

¿Estás interesado en productos Amazon sobre Desarrollo Ágil de Software?













Kanban
Autor: David J Anderson
>> España (amazon.es)
>> Latinoámerica (amazon.com)
Código Limpio
Autor: Robert C. Martin
>>España(amazon.es)
>> Latinoámerica (amazon.com)
Gestión Ágil de Proyectos
Autor: Pablo Lledó
>>España(amazon.es)
>> Latinoámerica (amazon.com)
Diseño ágil con TDD
Autor: Carlos Ble Jurado
>> España(amazon.es)
>> Latinoámerica (amazon.com)


>> Visita nuestra sección de productos amazon

Referencia:

TDD in Practice - Dealing with Hard-To-Test Areas

Hacked on TDD and Jeremy’s First Rule of TDD

Otros artículos de esta serie

¿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”.

>> TDD y las pruebas de desarrollador

>> TDD Como llevarlo a la práctica

>> Test Driven Development (TDD): Ventajas y desventajas

>> 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

Desarrollo ágil, Scrum

No hay comentarios :

Publicar un comentario

Pmoinformatica.com," La Oficina de Proyectos de Informática ", es un participante en el Programa de Servicios de Amazon Associates LLC, un programa de publicidad de afiliación diseñado para proporcionar un medio para que sitios web puedan ganar honorarios por la publicidad y enlaces a amazon.com y amazon.es.