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é:
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:
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:
Otros componentes con posibles problemas
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.
¿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.
Tambíen puedes seguirnos al Twitter @PMOInformatica o página de Facebook
¿Estás interesado en productos Amazon sobre Desarrollo Ágil de Software?
>> 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
>> 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
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?
¿Buscas más información de metodologías ágiles?
¿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?.
¿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.
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)  |
| 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
>> 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