Automatizacion De Pruebas Unitarias - Historial de revisiones

190.69.1.62: /* Solución */

2010-08-12T13:41:00Z

‎Solución

201.251.185.130 en 14:40 31 ago 2009

2009-08-31T14:40:57Z

201.251.185.130 en 16:02 25 jul 2008

2008-07-25T16:02:01Z

201.251.182.130: 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...

2008-07-25T14:17:48Z

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

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

* [[Control De Versiones]]
* [[Automatizacion De Build]]
* [[Integracion Continua]]

===Ver también===
* [[Herramientas Para Pruebas Unitarias]]
* [[Prueba Unitaria]]
* [[Mock Object]]

===Reconocimientos===

* (BECK, 2004)
* (COCKBURN, 2001)
* (HUNT e THOMAS, 2004)
* (MCCONNELL, 2004)
* (RICHARDSON e GWALTNEY, 2005)

@@ Línea 18: / Línea 18: @@
 ==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" (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.

@@ Línea 40: / Línea 40: @@
 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==
@@ Línea 52: / Línea 51: @@
 * [[Prueba Unitaria]]
 * [[Mock Object]]
 ==Reconocimientos==
@@ Línea 61: / Línea 59: @@
 * (MCCONNELL, 2004)
 * (RICHARDSON e GWALTNEY, 2005)

@@ Línea 1: / Línea 1: @@
-===Contexto===
+==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===
+==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.
@@ 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.
-===Fuerzas===
+==Fuerzas==
 * 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.
-===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 [[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á.
-===Raciocinio===
+==Raciocinio==
 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===
+==Contexto Resultante==
 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===
+==Patrones Relacionados==
 * [[Control De Versiones]]
@@ Línea 48: / Línea 48: @@
 * [[Integracion Continua]]
-===Ver también===
+==Ver también==
 * [[Herramientas Para Pruebas Unitarias]]
 * [[Prueba Unitaria]]
@@ Línea 54: / Línea 54: @@
-===Reconocimientos===
+==Reconocimientos==
 * (BECK, 2004)