Diferencia entre revisiones de «Automatizacion De Pruebas Unitarias»
(→Solución) |
|||
| (No se muestra una edición intermedia de otro usuario) | |||
| Línea 18: | Línea 18: | ||
==Solución== | ==Solución== | ||
| − | Utilice una herramienta para la creación de la [[Prueba Unitaria]] automatizada, bien como herramientas que permitan la creación de | + | Utilice una herramienta para la creación de la [[Prueba Unitaria]] automatizada, bien como herramientas que permitan la creación de "Mock Object" (Objeto Falso) que imiten la funcionalidad de objetos reales. |
Siempre ejecute todas las pruebas unitarias automatizadas antes de hacer check-in de nuevos código en el repositorio de control de versiones. | Siempre ejecute todas las pruebas unitarias automatizadas antes de hacer check-in de nuevos código en el repositorio de control de versiones. | ||
| Línea 40: | Línea 40: | ||
La [[Automatizacion De Build]] debe tener tareas específicas para ejecutar todas las pruebas unitarias del proyecto. | La [[Automatizacion De Build]] debe tener tareas específicas para ejecutar todas las pruebas unitarias del proyecto. | ||
De este modo es posible ejecutar el conjunto de pruebas unitarias siempre que la [[Integracion Continua]] sea ejercida | De este modo es posible ejecutar el conjunto de pruebas unitarias siempre que la [[Integracion Continua]] sea ejercida | ||
| − | |||
==Patrones Relacionados== | ==Patrones Relacionados== | ||
| Línea 52: | Línea 51: | ||
* [[Prueba Unitaria]] | * [[Prueba Unitaria]] | ||
* [[Mock Object]] | * [[Mock Object]] | ||
| − | |||
==Reconocimientos== | ==Reconocimientos== | ||
| Línea 61: | Línea 59: | ||
* (MCCONNELL, 2004) | * (MCCONNELL, 2004) | ||
* (RICHARDSON e GWALTNEY, 2005) | * (RICHARDSON e GWALTNEY, 2005) | ||
| + | |||
| + | [[Category:TDD]] | ||
Revisión actual del 13:41 12 ago 2010
Contenido
Contexto
Un proceso de desarrollo de software que necesita mejorar la calidad y reducir el número de defectos. El proyecto ya debe poseer Automatizacion De Build y Control De Versiones.
Problema
La calidad del software es una tarea de todo el equipo. Dejar la cuestión de la calidad del código apenas a cargo de un grupo de analistas de pruebas y de calidad es un riesgo. Aumentar la confianza de los programadores en relación a eventuales modificaciones en el código es esencial en Codigo Legado complejo. Facilitar las pruebas de los programadores es fundamental, para que ellos puedan probar su código isoladamente y de esa forma no encuentren dificultades en probar siempre todo lo que producen.
Fuerzas
- El costo de detección y corrección de un defecto es mayor cuando ocurre en la etapa de homologación.
- Las partes complejas de un software acostumbran tener mas defectos y tienden a ser recurrentes.
- La flexibilidad de modificar aumenta la complejidad. Siempre que un desarrollador trabaja con un código complejo, le lleva un tiempo para que él pueda entender nuevamente la solución.
- Corregir un defecto ocasionalmente causa problemas en otra parte del software.
Solución
Utilice una herramienta para la creación de la Prueba Unitaria automatizada, bien como herramientas que permitan la creación de "Mock Object" (Objeto Falso) que imiten la funcionalidad de objetos reales.
Siempre ejecute todas las pruebas unitarias automatizadas antes de hacer check-in de nuevos código en el repositorio de control de versiones.
Cuando un nuevo defecto es descubierto, lo primero que se hace es una prueba unitaria automatizada para probar el defecto. Luego el mismo es corregido. De este modo es mas difícil que el defecto vuelva, ya que en el caso que un desarrollador cometa el mismo error nuevamente, la batería de pruebas unitarias automatizadas lo detectará.
Raciocinio
Las pruebas unitarias reducen el tiempo que gasta el equipo para identificar y corregir defectos (HUNT e THOMAS, 2004). Un conjunto de pruebas unitarias automatizadas también aumenta la confianza del equipo cuando necesita realizar cambios para inclusión de nuevas funcionalidades o la alteración de funcionalidades existentes.
La automatización de pruebas unitarias aumenta la calidad al facilitar la detección de defectos mas rápido en el ciclo de desarrollo. El tiempo de vida de un software tiende a aumentar debido a la "red de seguridad" que da la batería de pruebas unitarias.
Contexto Resultante
El proyecto posee un conjunto de pruebas unitarias automatizadas que es ejecutada siempre que un desarrollador le desee.
El código de las pruebas unitarias generados por la Automatizacion De Pruebas Unitarias se deben almacenar como parte del proyecto junto con el código fuente del software en la herramienta de Control De Versiones. La Automatizacion De Build debe tener tareas específicas para ejecutar todas las pruebas unitarias del proyecto. De este modo es posible ejecutar el conjunto de pruebas unitarias siempre que la Integracion Continua sea ejercida
Patrones Relacionados
Ver también
Reconocimientos
- (BECK, 2004)
- (COCKBURN, 2001)
- (HUNT e THOMAS, 2004)
- (MCCONNELL, 2004)
- (RICHARDSON e GWALTNEY, 2005)
