Diferencia entre revisiones de «Pruebas Unitarias»
Línea 29: | Línea 29: | ||
*Para aplicar el Patrón de Producto: | *Para aplicar el Patrón de Producto: | ||
− | </ul></div> | + | </ul></div><br><br> |
<div id="section_6"> | <div id="section_6"> |
Revisión de 15:22 29 mar 2015
Tiempo de Desarrollo
- Para adquirir el conocimiento necesario para desarrollar el producto software:
- Para crear el Patrón de Producto: 45 minutos.
- Para aplicar el Patrón de Producto:
Patrones Relacionados
Herramientas de Soporte
- Será necesario un editor de texto como OpenOffice Writer o Microsoft Word.
- Será necesario un editor de hojas de cálculo como OpenOffice Calc o Microsoft Excel
- Además de una herramienta como Visual Paradigm for UML para la realización de los diagramas expuestos.
Contexto Inicial
Este producto puede usarse en cualquier proyecto en el se deban probar por separado las tareas a implementar de acuerdo a un conjunto de casos de prueba previamente identificados.
Esto indica al programador que es lo que tiene que hacer cuando codifica.Los requisitos aparecen en forma de pruebas de unidad.Se sabe cuando se ha terminado porque se superan todos los test de unidad.El beneficio que tiene de ello el diseño, es que en los test de unidad se pone aquello que es importante para el cliente.
Contexto Resultante
Los desarrolladores obtienen una serie de resultados unitarios para cada caso de prueba asociado a una tarea.
Problema
Los desarrolladores deben ser capaces de conseguir que las pruebas unitarias de los casos de prueba, por separado, sean satisfactorias para poder continuar con el proceso.
Un pequeño problema es que los test en si mismo pueden tener errores y esto conduce a que las pruebas unitarias no realicen su actividad de forma correcta.
Restricciones (Forces)
- Características de las organizaciones: Este patrón puede utilizarse en los proyectos existentes en cualquier tipo de compañía.
- Tipo de sistema a desarrollar: Este producto puede utilizarse en proyectos en los que los requerimientos de usuario sean cambiantes.
- Tipo de Cliente: Debe existir, o debe conseguirse, que el área de negocio destinataria del desarrollo se implique en la consecución del mismo.
- Heurísticas de uso: :Si se necesita disponer urgentemente del aplicativo o de algunas de sus funcionalidades.
Lecciones Aprendidas
- Si no funcionan las pruebas unitarias hay que corregirlas lo antes posible. Este es el trabajo más importante del equipo. Debido a esto, hay que mantener el equilibrio en el tiempo que se dedica a la realización de las pruebas y a la corrección de las que no sean satisfactorias.
- La pareja de desarrolladores realizan pruebas unitarias sobre cada uno de los casos de prueba por separado.
- El archivo Pruebas.xls es un documento genérico, para todos los tipos de prueba con la casilla pruebas unitarias marcada, que aglutina todos los casos de prueba para una tarea en cuestión.
Conocimientos y Habilidades Básicos
Conocimientos
- Conocimiento del estándar de codificación que define la propiedad del código compartido así como las reglas para escribir y documentar el código y la comunicación entre diferentes piezas de código desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el código en el sistema se vea como si hubiera estado escrito por una sola persona.
- Conocimiento de la visión común de cómo funciona el programa en el que se desarrollan las actividades.
Habilidades
- Capacidad de trabajo en grupo.Todos en un equipo XP contribuyen de la manera que pueden.
- Predicción de qué se habrá terminado para la fecha de entrega, y determinación de qué hacer después.
- Capacidad de programación de a pares.Además de generar mejor código y pruebas, sirve para comunicar el conocimiento a través de los equipos.
Recursos de Información
- Álvarez, José R. y Arias Manuel. Método Extreme programming.Recuperado el 2010-03-05 de http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node61.html
- Anaya Villegas, Adrian. A proposito de programación extrema XP(extreme Programming).Recuperado el 2010-02-10 de http://www.monografias.com
- Beck, K.(2000), Una explicación de la programación extrema. Aceptar el cambio. Ed. Addisson Wesley.
- De Seta, Leonardo. Una introducción a Extreme Programming.Recuperado el 2010-03-02 de http://www.dosideas.com/noticias/metodologias/822-una-introduccion-a-extreme-programming.html
- Extreme Programming: A gentle introduction. Recuperado el 2010-03-15 de http://www.extremeprogramming.org/
- Joskowicz, José. Reglas y prácticas en Xtreme Programming. Recuperado el 2010-03-15 de http://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf
- Letelier, Patricio y Panadés Mª Carmen. Metodologías Ágiles en el desarrollo de software: extreme programming. Recuperado el 2010-03-15 de http://www.willydev.net/descargas/masyxp.pdf
- Newkirk, James y Martin, Robert C.(2001), La programación Extrema en la Práctica.Ed Addisson Wesley.