Diferencia entre revisiones de «Automatizacion De Pruebas Unitarias»
(Página nueva: ===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 [[Contr...) |
|||
| Línea 1: | Línea 1: | ||
| − | + | ==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]]. | 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. | 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. | ||
| Línea 9: | Línea 9: | ||
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. | 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. | * El costo de detección y corrección de un defecto es mayor cuando ocurre en la etapa de homologación. | ||
| Línea 16: | Línea 16: | ||
* Corregir un defecto ocasionalmente causa problemas en otra parte del software. | * 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]] que imiten la funcionalidad de objetos reales. | Utilice una herramienta para la creación de la [[Prueba Unitaria]] automatizada, bien como herramientas que permitan la creación de [[Mock Object]] que imiten la funcionalidad de objetos reales. | ||
| Línea 25: | Línea 25: | ||
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á. | 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). | Las pruebas unitarias reducen el tiempo que gasta el equipo para identificar y corregir defectos (HUNT e THOMAS, 2004). | ||
| Línea 33: | Línea 33: | ||
| − | + | ==Contexto Resultante== | |
El proyecto posee un conjunto de pruebas unitarias automatizadas que es ejecutada siempre que un desarrollador le desee. | El proyecto posee un conjunto de pruebas unitarias automatizadas que es ejecutada siempre que un desarrollador le desee. | ||
| Línea 42: | Línea 42: | ||
| − | + | ==Patrones Relacionados== | |
* [[Control De Versiones]] | * [[Control De Versiones]] | ||
| Línea 48: | Línea 48: | ||
* [[Integracion Continua]] | * [[Integracion Continua]] | ||
| − | + | ==Ver también== | |
* [[Herramientas Para Pruebas Unitarias]] | * [[Herramientas Para Pruebas Unitarias]] | ||
* [[Prueba Unitaria]] | * [[Prueba Unitaria]] | ||
| Línea 54: | Línea 54: | ||
| − | + | ==Reconocimientos== | |
* (BECK, 2004) | * (BECK, 2004) | ||
Revisión del 16:02 25 jul 2008
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 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)
