lunes, 25 de junio de 2012

Historias de Usuario vs. Casos de Uso


Fuente: sixservix.com

Escribiendo documentación sobre metodologías ágiles en general y ‘buenas prácticas’ a la hora de crear historias de usuario en particular, me encontré con el estupendo post de Jean Claude Grosjean sobre las diferencias existentes entre un caso de uso y una historia de usuario.
Puede ser muy útil explicar estas diferencias, sobre todo cuando -como es mi caso- intentas convertir al agilismo a una audiencia escéptica. Así que, refiné el artículo original, lo traduje al castellano y, sobre todo, lo tabulé para poder incrustarlo fácilmente en documentación o presentaciones. Aquí tenéis el resultado.



Estructura de una Historia de Usuario

Fuente: sixservix.com


  • ID: Identificador de la historia de usuario
  • TÍTULO: Título descriptivo de la historia de usuario
  • DESCRIPCIÓN: Descripción sintetizada de la historia de usuario
  • ESTIMACIÓN: Estimación del coste de implementación en unidades de desarrollo (estas unidades representarán el tiempo teórico de desarrollo/hombre que se estipule al comienzo del proyecto)
  • PRIORIDAD: Prioridad en la implementación de la historia de usuario respecto al resto de las historias de usuario. A mayor número, mayor prioridad. Otra aproximación a la priorización de tareas se hace a través del método MoSCoW:
    • M – Must, se debe completar este requerimiento para finalizar el proyecto
    • S – Should, se debe completar este proyecto por todos los medios, pero el éxito del proyecto no depende de él.
    • C – Could, se debería completar este requerimiento si su implementación no afecta a la consecución de los objetivos principales del proyecto.
    • W – Would, se puede completar este requerimiento si sobra tiempo de desarrollo (o en futuras versiones del mismo)
  • DEPENDENCIAS: Una historia de usuario no debería ser dependiente de otra historia, pero a veces es inevitable. En este apartado se indicarían los IDs de las tareas de las que depende una tarea
El ciclo de vida de la tarjeta se compone de tres fases, conocidas como “Las 3 C” por sus iniciales en inglés (Card, Conversation, Confirmation):
  • TARJETA (Card), la creación de la tarjeta en sí, con la estructura definida anteriormente y que sirve para determinar QUÉ se debe hacer y cómo planificarlo.
  • CONVERSACION (Conversation), representado por pequeños documentos y anotaciones que sirven para aportar detalles y refinar los datos sobre las características del requerimiento.
  • CONFIRMACIÓN (Confirmation), o pruebas de aceptación. Pruebas consensuadas entre el cliente y el desarrollador y que el código debe superar para dar como finalizada la implementación del requerimiento.
(Gracias a Vicenç y Jasosa por el ejemplo incluido en la tarjeta)

        

Revisando: Programación Extrema XP (25/06/2012)


  • Programación extrema [Wikipedia].
  • A propósito de programación extrema XP (eXtreme Programming) [Monografia].
  • XP PROGRAMACION EXTREMA [Presentacion].
  • Las prácticas de Extreme Programming [Wikipedia traducción automática].
  • Extreme Programming Explained: Embrace Change [Libro en ingles].
  • Reglas y Prácticas en eXtreme Programming [PDF].
  • Una explicación de la programación extrema (XP) [PDF].
  • Extreme programming [DOC].
  • Desarrollo en comunidad con eXtreme Programming [PDF].
  • Una explicación de la programación extrema XP [PPT].
  • Metodología XP [Video].
  • XP - Decisión de Negocio [Video].
  • Programacion Extrema - Tests Unitarios - Tarea Zombies - Explicacion Inversion de Control [Video].
  • Programación Extrema (Exposicion de Maestria 2007) [Presentación].
  • Introducción Ágil a eXtreme Programming [Presentación].
  • Seminario MetodologíAs áGiles Y Xp, Extreme Programming [Presentación].
  • Métodos Ágiles-Scrum y XP [Presentación].
  • XPWeb: gestión de proyectos Extreme Programming.


Programación extrema [Wikipedia]

Fuente: es.wikipedia.org

La programación extrema o eXtreme Programming (XP) es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

Valores

Los Valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming Explained. Los cinco valores se detallan a continuación:
  • Simplicidad:
La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple a medida que crece. También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí que el código esté autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, métodos y clases. Los nombres largos no decrementan la eficiencia del código ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen actualmente. Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo.
  • Comunicación:
La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado. Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método. Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide qué características tienen prioridad y siempre debe estar disponible para solucionar dudas.
  • Retroalimentación (feedback):
Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante. Considérense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código.
  • Coraje o valentía:
Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir demasiado tiempo y trabajo para implementar todo lo demás del proyecto. La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran mas fácilmente. Otro ejemplo de valentía es saber cuando desechar un código: valentía para quitar código fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirtió en crear ese código. Además, valentía significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, sólo si es persistente.
  • Respeto:
El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo y elevando el ritmo de producción en el equipo.

Características fundamentales

Las características fundamentales del método son:
  • Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
  • Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.
  • Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
  • Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
  • Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
  • Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
  • Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
  • Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

Véase también

Enlaces externos





A propósito de programación extrema XP (eXtreme Programming)

Fuente: monografias.com



XP PROGRAMACION EXTREMA [Presentación]

Fuente: es.scribd.com

Cargado por Dennis Zamo Adunay
       


Las prácticas de Extreme Programming [wikipedia traducción automática]

Fuente: en.wikipedia.org

La programación extrema (XP) es un popular ágiles de desarrollo de software metodología utilizada para la aplicación de software de proyectos. Este artículo detalla las prácticas utilizadas en esta metodología. La programación extrema tiene 12 prácticas, agrupadas en cuatro áreas, derivadas de las mejores prácticas de ingeniería de software . [1]

escala de Fine

La programación en parejas

Par de programación significa que todo el código es producido por dos personas en una tarea de programación en una estación de trabajo. Un programador tiene el control de la estación de trabajo y está pensando principalmente acerca de la codificación en detalle. El otro programador se centra más en el cuadro grande, y está continuamente revisando el código que está siendo producido por la primera programadora. Los programadores cambiará roles con regularidad.
Las parejas no son fijas: se recomienda que los programadores tratan de mezclar tanto como sea posible, de manera que todo el mundo sabe lo que cada uno está haciendo, y todo el mundo pueda familiarizarse con el sistema en su conjunto. De esta manera, la programación en parejas también pueden mejorar la comunicación de todo el equipo. (Esto también va mano a mano con el concepto de propiedad colectiva).

Juego de Planificación

El proceso de planificación principal dentro de la programación extrema se llama el Juego de Planificación. El juego es una reunión que se produce una vez por iteración, por lo general una vez por semana. El proceso de planificación se divide en dos partes:
  • Planificación de autorización: Esta se centra en determinar qué requisitos se incluyen en el que a corto plazo las liberaciones, y cuándo deben ser entregados. Los clientes y los desarrolladores son parte de esto. Planificación de la difusión consiste en tres fases:
    • Fase de Exploración: En esta fase, el cliente proporcionará una lista de requisitos de alto valor para el sistema. Estos serán escritas en la historia del usuario de tarjetas.
    • Fase de Compromiso: Dentro de la fase de compromiso de negocios y los desarrolladores se comprometen a la funcionalidad que se incluirán y la fecha de la próxima versión.
    • Fase de dirección: En la fase de dirección del plan se puede ajustar, los nuevos requisitos se pueden añadir y / o requisitos existentes pueden ser cambiadas o eliminadas.
  • Planificación de la iteración: Este planes de las actividades y tareas de los desarrolladores. En este proceso el cliente no está implicado. Planificación de la iteración también se compone de tres fases:
    • Fase de Exploración: En esta fase, el requisito será traducida a diferentes tareas. Las tareas se graban en tarjetas de trabajo.
    • Fase de Compromiso: Las tareas serán asignadas a los programadores y el tiempo que tarda en completar se estimará.
    • Dirigir Fase: Las tareas se llevan a cabo y el resultado final se corresponde con la historia de usuario original.
El propósito del juego de planificación es guiar el producto en la entrega. En lugar de predecir las fechas exactas de cuando entregas serán necesarios y producido, lo cual es difícil de hacer, su objetivo es "dirigir el proyecto" en la prestación de utilizar un enfoque directo. [2]

la planificación de lanzamiento

Exploración fase de
Este es un proceso iterativo de reunir los requisitos y la estimación del impacto en el trabajo de cada uno de esos requisitos.
  • Escribir una historia: El negocio ha llegado con un problema, durante una reunión, el desarrollo se tratará de definir este problema y obtener los requisitos. Basado en el problema de negocio, una historia ( historia de usuario ) tiene que ser por escrito. Esto se hace por las empresas, en el que señalan lo que quieren una parte del sistema de hacer. Es importante que el desarrollo no tiene influencia en esta historia. La historia está escrita en una tarjeta de historia de usuario.
  • Estimar una historia: el Desarrollo calcula cuánto tiempo se tardará en poner en práctica el trabajo que implica la tarjeta de la historia. El desarrollo también pueden crear soluciones de espiga para analizar o resolver el problema. Estas soluciones se utilizan para la estimación y se desecha una vez que todo el mundo tiene una visualización clara del problema. Una vez más, esto no puede influir en los requerimientos del negocio.
  • Dividir una historia: Cada complejidad del diseño crítico tiene que ser abordado antes de iniciar la planificación de la iteración. Si el desarrollo no es capaz de estimar la historia, tiene que ser dividido y vuelto a escribir.
Cuando el negocio no puede venir con los requisitos más, se procede a la fase de compromiso.
fase de Compromiso
Esta fase consiste en la determinación de los costos, beneficios y el impacto previsto. Tiene cuatro componentes:
  • Ordenar por Valor: tipo de negocio de las historias de los usuarios por valor de negocio .
  • Ordenar por riesgo: tipo de desarrollo de las historias de los riesgos.
  • Velocidad de Ajuste: Desarrollo determina a qué velocidad se puede llevar a cabo el proyecto.
  • Elija ámbito de aplicación: Las historias de usuario que se terminarán en la próxima versión será recogido. Basado en las historias de los usuarios la fecha de lanzamiento está determinada.
Ordenar por valor de
El lado comercial tipo las historias de los usuarios por el valor del negocio. Se va a organizar en tres grupos:
  • Crítica: historias sin las cuales el sistema no puede funcionar o no tiene sentido.
  • Significativo valor comercial : no críticos historias de usuario que tienen un importante valor empresarial.
  • Es bueno tener: Historias de usuarios que no tienen valor comercial significativo.
Ordenar por riesgo
Los desarrolladores de clasificar los casos de uso por el riesgo. También se clasifican en tres grupos: historias de riesgo bajo, medio y alto de los usuarios. El siguiente es un ejemplo de una aproximación a este:
  • Determinar el Índice de Riesgo: Dar a cada historia de usuario un índice de 0 a 2 en cada uno de los siguientes factores:
    • Integridad (no sabemos todos los detalles de la historia?)
      • Completa (0)
      • Incompleta (1)
      • Desconocido (2)
    • Volatilidad (es probable que cambie?)
      • bajo (0)
      • medio (1)
      • de alto (2)
    • Complejidad (lo difícil que es construir?)
      • sencillo (0)
      • estándar (1)
      • complejo (2)
Todos los índices de una historia de usuario se agregan, la asignación de las historias de los usuarios un índice de riesgo de baja (0-1), mediano (2-4) o alto (5-6).
Fase de Dirección
Dentro de la fase de dirección de los programadores y gente de negocios puede "dirigir" el proceso. Es decir, pueden hacer cambios. Las historias individuales de los usuarios, o las prioridades relativas de las historias de usuarios, puede cambiar; estimaciones podrían resultar erróneos. Esta es la oportunidad para ajustar el plan en consecuencia.

planificación de la iteración

Exploración fase de
La fase de exploración de la planificación de la iteración se trata de la creación de tareas y la estimación de su tiempo de ejecución.
  • Traducir el requisito de tareas: Coloque las tarjetas de trabajo.
  • Combinar / Dividir tarea: Si el programador no puede estimar la tarea, porque es demasiado pequeño o demasiado grande, el programador tendrá que combinar o dividir la tarea.
  • Estimación de la tarea: Calcule el tiempo que se necesita para poner en práctica la tarea.
fase de Compromiso
Dentro de la fase de compromiso de los programadores de planificación de iteración se les asignan tareas que hacen referencia a los casos de uso diferentes.
  • Un programador acepta una tarea: Cada programador elige una tarea para la cual él o ella asume la responsabilidad.
  • Programador estima que la tarea: Debido a que el programador es ahora responsable de la tarea, él o ella debe dar a la estimación final de la tarea.
  • Selección del factor de carga: El factor de carga representa la cantidad ideal de la práctica en el tiempo de desarrollo por el programador en una iteración. Por ejemplo, en una semana de 40 horas, con 5 horas dedicadas a las reuniones, esto sería no más de 35 horas.
  • Equilibrio: Cuando todos los programadores dentro del equipo se han asignado las tareas, se hace una comparación entre el tiempo estimado de las tareas y el factor de carga. A continuación, las tareas se compensan entre los programadores. Si un programador está excesivamente comprometido, otros programadores deben hacerse cargo de algunas de las tareas de sus, y viceversa.
Fase de Dirección
La ejecución de las tareas se lleva a cabo durante la fase de dirección de la planificación de la iteración.
  • Obtenga una tarjeta de tarea: El programador tiene la tarjeta de tarea para una de las tareas a las que él o ella ha cometido.
  • Encuentre un socio: El programador incorpora esta tarea, junto con otro programador. Esto se discute en la práctica de la programación en parejas .
  • Diseño de la tarea: Si es necesario, a los programadores a diseñar la funcionalidad de la tarea.
  • Escribir prueba de unidad : Antes de que los programadores empiezan a codificar la funcionalidad que escribir primero las pruebas automatizadas. Esto se discute en la prueba de la unidad práctica.
  • Escriba el código: Los programadores empiezan a codificar.
  • Ejecutar la prueba: Las pruebas unitarias se realizan para probar el código.
  • Refactorizar : eliminar cualquier código de los olores desde el código.
  • Ejecutar funcional de prueba: las pruebas funcionales (sobre la base de los requisitos en la historia de usuario asociada y la tarjeta de trabajo) se ejecutan.

Test Driven Development

Las pruebas unitarias son pruebas automatizadas que ponen a prueba la funcionalidad de las piezas del código (por ejemplo, clases, métodos). En XP, las pruebas unitarias se escriben antes que el código final se codifica. Este enfoque tiene por objeto estimular al programador a pensar sobre las condiciones en que su código puede fallar. XP dice que el programador ha terminado con una determinada pieza de código cuando él o ella no puede llegar a ninguna otra condición en la que el código puede fallar.

Todo el equipo


En XP, el "cliente" no es el que paga la cuenta, pero el que realmente utiliza el sistema. XP dice que el cliente debe tener a la mano en todo momento y disponibles para preguntas. Por ejemplo, el equipo de desarrollo de un sistema de administración financiera debe incluir un administrador financiero.


Proceso continuo

La integración continua

El equipo de desarrollo siempre debe estar trabajando en la versión más reciente del software. Dado que diferentes miembros del equipo pueden tener versiones guardadas localmente con varios cambios y mejoras, deben tratar de subir su versión actual en el repositorio de código de cada pocas horas, o cuando una ruptura significativa se presenta. La integración continua evitará retrasos más tarde en el ciclo de los proyectos, causada por problemas de integración.

Diseño de mejora

Debido a que la doctrina defiende la programación de XP sólo lo que se necesita hoy en día, y su aplicación más sencilla posible, a veces esto puede resultar en un sistema que se ha quedado atascado. Uno de los síntomas de esto es la necesidad de una doble (o múltiple) de mantenimiento: cambios funcionales empezar a requerir cambios en las múltiples copias de la misma (o similar) de código. Otro síntoma es que los cambios en una parte del código afectan a muchas otras partes. XP doctrina dice que cuando esto ocurre, el sistema le está diciendo a refactorizar el código, cambiando la arquitectura, por lo que es más simple y más genérico.

Las pequeñas emisiones

La entrega del software se realiza a través de lanzamientos frecuentes de la funcionalidad en vivo, creando un valor concreto. Las pequeñas emisiones ayudar al cliente a adquirir confianza en el progreso del proyecto. Esto ayuda a mantener el concepto de todo el equipo que el cliente puede llegar a sus sugerencias sobre el proyecto basado en la experiencia real.


La comprensión compartida

La codificación estándar

La codificación estándar es un conjunto acordado de normas que el equipo de desarrollo de acuerdo a adherirse a lo largo del proyecto. La norma especifica un estilo consistente y el formato de código fuente, en el lenguaje de programación elegido, así como diversas construcciones de programación y los patrones que deben ser evitados con el fin de reducir la probabilidad de defectos. [3] El estándar de codificación puede ser una serie de convenciones estándar especificada por el fabricante idioma (por ejemplo, las convenciones de codificación para el lenguaje de programación Java, recomendado por Sun), o personalizado definido por el equipo de desarrollo.

Propiedad colectiva del código

Propiedad colectiva del código significa que cada uno es responsable de todo el código, lo que, a su vez, significa que todo el mundo se le permite cambiar cualquier parte del código. La programación en parejas contribuye a esta práctica: por el trabajo en parejas diferentes, todos los programadores la oportunidad de ver todas las partes del código. Una gran ventaja reclamada por la propiedad colectiva es que se acelera el proceso de desarrollo, ya que si se produce un error en el código de cualquier programador puede arreglarlo.
Al dar a todos los programadores el derecho a modificar el código, no hay riesgo de errores que se introducen por los programadores que creen que saben lo que están haciendo, pero no prevén ciertas dependencias. Suficientemente bien definidas las pruebas de unidad frente a este problema: si las dependencias imprevistas crear errores, a continuación, cuando se ejecutan las pruebas unitarias, se muestran las fallas.

El diseño simple

Los programadores deben tener un "simple es lo mejor" para el diseño de software. Cada vez que una nueva pieza de código está escrito, el autor debe preguntarse a sí mismos 'hay una manera más sencilla de introducir la misma funcionalidad?'. Si la respuesta es sí, el curso más sencillo debe ser elegido. Refactorización también se debe utilizar, para hacer más sencillo el código complejo.

Sistema de la metáfora


La metáfora del sistema es una historia que todo el mundo - los clientes, programadores y administradores - se puede decir acerca de cómo funciona el sistema. Es un concepto de nomenclatura para las clases y métodos que deberían hacer que sea fácil para un miembro del equipo de adivinar la funcionalidad de un método particular de clase /, a partir de su propio nombre. Por ejemplo, un sistema de bibliotecas pueden crear loan_records (clase) para los prestatarios (clase), y si el tema se convirtiera en mora, puede realizar una operación de make_overdue en un catálogo (de clase). Para cada clase o el funcionamiento de la funcionalidad es obvio para todo el equipo.


Programador de bienestar

ritmo sostenible

El concepto es que los programadores o desarrolladores de software no deben trabajar más de 40 horas a la semana, y si hay horas extras de una semana, que la semana que viene no debe incluir más horas extras. Dado que los ciclos de desarrollo son los ciclos cortos de integración continua y completa los ciclos de desarrollo (la liberación) son más frecuentes, los proyectos de XP no siguen la hora de la verdad típico que requieren otros proyectos (que requiere horas extras).
Además, se incluyen en este concepto es que las personas se desempeñan mejor y más creativa si están descansados.
Un factor clave para lograr ritmo sostenible es frecuente el código de combinación de correspondencia y siempre ejecutable y prueba de código cubierto por la alta calidad. La forma en la refactorización constante de los miembros del equipo de trabajo cumplir con la mente fresca y alerta. La manera intensa de colaboración de trabajo dentro del equipo conduce a la necesidad de recargar los fines de semana.
Bien probado, de forma continua integrada, código de frecuencia desplegada y ambientes también reducir al mínimo la frecuencia de los problemas de producción y cortes inesperados, y la asociada después de horas de trabajo noches y fines de semana que se requiere.


Véase también


Referencias

  1. ^ Beck, K. Extreme Programming Explained: Embrace Change segundo. ed. Addison-Wesley, 2000 pp 54
  2. ^ Melnik, Grigori; Maurer, Frank (2004). "Introducción a los Métodos Ágiles: Tres años de experiencia". Actas de la 30 ª Conferencia Euromicro. IEEE. . pp 334-341 DOI : 10.1109/EURMIC.2004.1333388 .
  3. ^ . Kolawa, Adán, Huizinga, Dorota (2007) la prevención de defectos Automatizado: Las Mejores Prácticas en la Gestión de Software . Wiley-IEEE Computer Society Press. pág. 75. ISBN 0-470-04212-5 .


Enlaces externos





Extreme Programming Explained: Embrace Change (Libro en ingles)

Fuente: books.google.com.ar


Ver Libro ...

Escrito por Kent Beck




Reglas y Prácticas en eXtreme Programming [PDF]

Fuente: etnassoft.com

Ficha Técnica:
  • Título: Reglas y Prácticas en eXtreme Programming
  • Autor(es):José Joskowicz
  • Publicación:2008
  • Editorial:Autoedición
  • Núm. Páginas:22p.
  • Tamaño:93 Kbs (zip)
  • Idioma:Español

Contenido

“Extreme Programming” o “Programación Extrema” es una de las llamadas metodologías ágiles de desarrollo de software más exitosas y controversiales de los tiempos recientes. El presente trabajo presenta un resumen de las características más destacables de esta metodología, incluyendo las fases de su ciclo de vida, las reglas y prácticas propuestas, sus valores y su aplicabilidad.
Finalmente se presentan algunas críticas, y se cita el resultado de encuestas recientes realizadas acerca del uso y éxito de las prácticas de ésta nueva metodología.
Extreme Programming (XP) surge como una nueva manera de encarar proyectos de software, proponiendo una metodología basada esencialmente en la simplicidad y agilidad. Las metodologías de desarrollo de software tradicionales (ciclo de vida en cascada, evolutivo, en espiral, iterativo, etc.) aparecen, comparados con los nuevos métodos propuestos en XP, como pesados y poco eficientes. La crítica más frecuente a estas metodologías “clásicas” es que son demasiado burocráticas. Hay tanto que hacer para seguir la metodología que, a veces, el ritmo entero del desarrollo se retarda. Como respuesta a esto, se ha visto en los últimos tiempos el surgimiento de “Metodologías Ágiles”. Estos nuevos métodos buscan un punto medio entre la ausencia de procesos y el abuso de los mismos, proponiendo un proceso cuyo esfuerzo valga la pena.

Ing. José Joskowicz




Una explicación de la programación extrema (XP) [PDF]

Fuente: docs.google.com

V Encuentro usuarios xBase 2003 MADRID



Manuel Calero Solís.




Extreme programming [DOC]

Fuente: docs.google.com

Fausto Alberto Paredes Villarreal
Ingeniería de Software

   


Desarrollo en comunidad con eXtreme Programming [PDF]

Fuente: docs.google.com




Una explicación de la programación extrema XP [PPT]

Fuente: docs.google.com


Metodología XP [Video]

Fuente: youtube.com

Quinto grupo en la serie de exposiciones de Analisis y Diseño de Sistemas de Informacion. Universidad de Oriente Nucleo Monagas

1

2

Subido por  el 22/11/2010




XP - Decisión de Negocio [Video]

Fuente: youtube.com

Extreme Programming es una metodología que abraza el cambio; que mantiene competitiva a las empresas adaptando sus sistemas a las variaciones en el mercado. Seleccionar XP como metodología de desarrollo es una decisión estratégica basada en adquirir y mantener ventajas competitivas en el negocio.

Este video fue realizado como parte del Taller de Introducción a XP, dictado por Imolko.


Subido por  el 31/08/2010




Programacion Extrema - Tests Unitarios - Tarea Zombies - Explicacion Inversion de Control [Video]

Fuente: youtube.com

Video realizado para el curso de Programación Extrema impartido por imolko.com. Imolko es una empresa dedicada a servicios de mercadeo electrónico en Internet que utiliza Programación Extrema como metodología de desarrollo de software.

En este video se explica de una forma muy sencilla, cuál es el concepto de inversión de control y por qué es necesario entenderlo para realizar tests unitarios.

1

2

Subido por  el 25/03/2010




Programación Extrema (Exposicion de Maestria 2007) [Presentación]

Fuente:  slideshare.net


by Edgar Espinoza Silverio on Jul 13, 2008



Introducción Ágil a eXtreme Programming [Presentación]

Fuente: slideshare.net

Introducción resumida a Extreme Programming, actualizada a Agosto de 2008


by ChileAgil on Apr 12, 2008




Seminario MetodologíAs áGiles Y Xp, Extreme Programming [Presentación]

Fuente: slideshare.net



by guest123148 on Jul 09, 2008




Métodos Ágiles-Scrum y XP - [Presentación]

Fuente: slideshare.net



by iscrquinter on Dec 07, 2009

                                 


XPWeb: gestión de proyectos Extreme Programming

Fuente: navegapolis.net

XPWeb es una herramienta web para la gestión de proyectos con Extreme Programming; de uso gratuito con licencia GNU.
Requisitos: PHP4 (recomendado 5), Apache, MySQL (también postgresql). Hay versión en español y cubre todas las funcionalidades básicas para dar soporte a las prácticas de Extreme Programming. Integra una ayuda muy completa.
Hay una demo "on-line" para verlo en funcionamiento, aunque ahora mismo está hospedada sobre PHP4 y no funciona la exportación XML.

                       

sábado, 23 de junio de 2012

Revisando: TDD, Desarrollo Guiado por Pruebas


  • Desarrollo guiado por pruebas (Definición Wikipedia).
  • Diseño Agil Con TDD (Libro).
  • Vídeo completo: Charla Pruebas Unitarias y TDD.
  • Introduction to Test-Driven Development (Ingles).
  • Introducción a Test Driven Development.
  • TDD Static vs. Dynamic.
  • Desarrollo guiado por pruebas - RemixFeb 8, 2011.
  • Desarrollo guiado por Pruebas y Refactorización.


Desarrollo guiado por pruebas (Definición Wikipedia)

Fuente: es.wikipedia.org/wiki

Desarrollo guiado por pruebas, o Test-driven development (TDD) es una práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione. La idea es que los requisitos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará el software cumple con los requisitos que se han establecido.

Contenido

Requisitos

Para que funcione el desarrollo guiado por pruebas, el sistema que se programa tiene que ser lo suficientemente flexible como para permitir que sea probado automáticamente. Cada prueba será suficientemente pequeña como para que permita determinar unívocamente si el código probado pasa o no la verificación que ésta le impone. El diseño se ve favorecido ya que se evita el indeseado "sobre diseño" de las aplicaciones y se logran interfaces más claras y un código más cohesivo. Frameworks como JUnit proveen de un mecanismo para manejar y ejecutar conjuntos de pruebas automatizadas.(Wly)

Ciclo de desarrollo conducido por pruebas

En primer lugar se debe definir una lista de requisitos y después se ejecuta el siguiente ciclo:
  1. Elegir un requisito: Se elige de una lista el requerimiento que se cree que nos dará mayor conocimiento del problema y que a la vez sea fácilmente implementable.
  2. Escribir una prueba: Se comienza escribiendo una prueba para el requisito. Para ello el programador debe entender claramente las especificaciones y los requisitos de la funcionalidad que está por implementar. Este paso fuerza al programador a tomar la perspectiva de un cliente considerando el código a través de sus interfaces.
  3. Verificar que la prueba falla: Si la prueba no falla es porque el requerimiento ya estaba implementado o porque la prueba es errónea.
  4. Escribir la implementación: Escribir el código más sencillo que haga que la prueba funcione. Se usa la metáfora "Déjelo simple" ("Keep It Simple, Stupid" (KISS)).
  5. Ejecutar las pruebas automatizadas: Verificar si todo el conjunto de pruebas funciona correctamente.
  6. Eliminación de duplicación: El paso final es la refactorización, que se utilizará principalmente para eliminar código duplicado. Se hacen de a una vez un pequeño cambio y luego se corren las pruebas hasta que funcionen.
  7. Actualización de la lista de requisitos: Se actualiza la lista de requisitos tachando el requisito implementado. Asimismo se agregan requisitos que se hayan visto como necesarios durante este ciclo y se agregan requerimientos de diseño (P. ej que una funcionalidad esté desacoplada de otra).
Tener un único repositorio universal de pruebas facilita complementar TDD con otra práctica recomendada por los procesos ágiles de desarrollo, la "Integración Frecuente". Integrar frecuentemente nuestro trabajo con el del resto del equipo de desarrollo permite ejecutar toda batería de pruebas y así descubrir si nuestra última versión es compatible con el resto del sistema. Es recomendable y menos costoso corregir pequeños problemas cada pocas horas que enfrentarse a problemas enormes cerca de la fecha de entrega fijada.

Características

Una ventaja de esta forma de programación es el evitar escribir código innecesario ("You Ain't Gonna Need It" (YAGNI)). Se intenta escribir el mínimo código posible, y si el código pasa una prueba aunque sepamos que es incorrecto nos da una idea de que tenemos que modificar nuestra lista de requerimientos agregando uno nuevo.
La generación de pruebas para cada funcionalidad hace que el programador confíe en el código escrito. Esto permite hacer modificaciones profundas del código (posiblemente en una etapa de mantenimiento del programa) pues sabemos que si luego logramos hacer pasar todas las pruebas tendremos un código que funcione correctamente.
Otra característica del Test Driven Development es que requiere que el programador primero haga fallar los casos de prueba. La idea es asegurarse de que los casos de prueba realmente funcionen y puedan recoger un error.

Ventajas

Los programadores que utilizan el desarrollo guiado por pruebas en un proyecto virgen encuentran que en raras ocasiones tienen la necesidad de utilizar el depurador o debugger.
A pesar de los elevados requisitos iniciales de aplicar esta metodología, el desarrollo guiado por pruebas (TDD) puede proporcionar un gran valor añadido en la creación de software, produciendo aplicaciones de más calidad y en menos tiempo. Ofrece más que una simple validación del cumplimiento de los requisitos, también puede guiar el diseño de un programa. Centrándose en primer lugar en los casos de prueba uno debe imaginarse cómo los clientes utilizarán la funcionalidad (en este caso, los casos de prueba). Por lo tanto, al programador solo le importa la interfaz y no la implementación. Esta ventaja es similar al diseño por convenio pero se parece a él por los casos de prueba más que por las aserciones matemáticas.
El poder del TDD radica en la capacidad de avanzar en pequeños pasos cuando se necesita. Permite que un programador se centre en la tarea actual y la primera meta es, a menudo, hacer que la prueba pase. Inicialmente no se consideran los casos excepcionales y el manejo de errores. Estos, se implementan después de que se haya alcanzado la funcionalidad principal. Otra ventaja es que, cuando es utilizada correctamente, se asegura de que todo el código escrito está cubierto por una prueba. Esto puede dar al programador un mayor nivel de confianza en el código.

Limitaciones

El desarrollo guiado por pruebas requiere que las pruebas puedan automatizarse. Esto resulta complejo en los siguientes dominios:
  • Interfaces Gráfica de usuario (GUIs), aunque hay soluciones parciales propuestas.
  • Objetos distribuidos, aunque los objetos simulados (MockObjects) pueden ayudar.
  • Bases de datos. Hacer pruebas de código que trabaja con base de datos es complejo porque requiere poner en la base de datos unos datos conocidos antes de hacer las pruebas y verificar que el contenido de la base de datos es el esperado después de la prueba. Todo esto hace que la prueba sea costosa de codificar, aparte de tener disponible una base de datos que se pueda modificar libremente.

Véase también

Enlaces externos





Diseño Agil Con TDD (Libro)

Fuente: scribd.com

Diseño Ágil con TDD El primer libro en español de Test Driven Development www.dirigidoportests.com

Diseño Agil con TDD
Carlos Bl´e Jurado y colaboradores.Prologo de Jos´e Manuel Beas
Primera Edici´on, Enero de 2010www.iExpertos.comEl libro se ha publicado bajo la Licencia Creative Commons


Sinopsis:
¿Dedicas una gran parte de tu tiempo de desarrollo a resolver incidencias de aplicaciones en producción?, ¿te enfrentas a sesiones de depuración interminables para encontrar la raíz de un problema?, ¿te extenúa descubrir innumerables fallos cada vez que introduces nuevas características a funcionalidades ya existentes?. Si respondes afirmativamente estas cuestiones y quieres promover el cambio, en este libro encontrarás la clave.

TDD es una técnica de desarrollo que se lleva aplicando durante años con gran éxito en lugares como EEUU y Reino Unido, sin embargo, la ausencia de información en español sobre la misma ha supuesto un freno para su difusión en los países hispano-parlantes. El objetivo de este libro es poner solución a este dilema y ofrecer una referencia completa, tanto teórica como práctica, que permita al lector iniciarse en su comprensión y aplicación.

A estas alturas sabemos que aprender nuevos lenguajes o frameworks incrementa nuestra productividad a corto plazo, pero los problemas más graves a los que nos enfrentamos siguen sin solución. TDD propone una nueva forma de afrontar los desarrollos atacando estas dificultades de frente y permitiendo entregar software más robusto y fiable. 

Con TDD, nuestro rendimiento a largo plazo sí se ve beneficiado, no olvidemos que uno de los factores con más influencia en la productividad de hoy es la calidad del código escrito ayer.

Diseño Ágil con TDD nos enseñará a:
* Escribir tests que aumenten la fiabilidad del código.
* Escribir tests de aceptación que nos ayudarán a centrarnos, específicamente, en el problema a resolver.
* Mejorar nuestros diseños para hacerlos más simples y flexibles.
* Escribir código fácil de mantener. Con TDD, los test son documentación viva y actualizada de nuestro código, la mejor documentación posible.
* Encajar TDD dentro del paradigma ágil y relacionarlo con otras técnicas como la integración continua.


– Alfredo Casado

Descargas:

Descarga: disenoAgilConTDD.pdf

Descarga (version para lectores electronicos): disenoAgilConTdd_ebook.pdf






Vídeo completo: Charla Pruebas Unitarias y TDD

Fuente: youtube.com

Charla a cargo de Pedro Luis Pérez. Pruebas Unitarias y TDD. Realizada el pasado Jueves 14 de Abril en el Salón de Actos de la Politécnica I. Por iniciativa del Club .Net de Alicante http://alicante.dotnetclubs.com


Subido por  el 18/04/2011




Introduction to Test-Driven Development (Ingles)

Fuente: youtube.com

This recorded webinar covers what TDD is, challenges that TDD may pose, and why organizations adopt TDD

Uploaded by  on Jun 22, 2011




Introducción a Test Driven Development

Fuente: youtube.com


Breve introducción a TDD en java usando Eclipse

1

2

Uploaded by  on Aug 30, 2010




TDD Static vs. Dynamic

Fuente: youtube.com

Comparación de la técnica de Test Driven Development entre lenguajes estáticamente tipados como Java y lenguajes dinámicamente tipados como Smalltalk

1

2

Uploader Comments ( hernanwilkinson )

  • Por más que el IDE es importante al momento de programar, lo que quiero que vean de fondo es el impacto de usar un lenguaje tipado en lo que respecta a la evolución de un modelo y como se distribuye el tiempo dependiendo del tipo de lenguaje

Uploaded by  on Oct 13, 2010




Desarrollo guiado por pruebas - RemixFeb 8, 2011

Fuente: blog.svpino.com

Hace poco más de dos años escribí un artículo para una revista cubana de telecomunicaciones e informática que nunca fue publicado. Después de esto decidí publicarlo en Google Knol, que por aquellos tiempos prometía mucho. Resulta ser que posiblemente el 90% de ustedes jamás hayan oído hablar de Knol, porque su existencia ha sido tan poco conocida como su capacidad de evolución. Resultado final: el artículo quedó olvidado en un rincón de Internet donde nadie jamás va a buscar nada.

A pesar que es de hace dos años (noviembre 2008), su contenido mantiene total vigencia, así que no hay mejor momento que este para re-publicarlo en el blog después de hacerle pequeños cambios. Además, viene como anillo al dedo después que fuera acusado por mi aversión a hacer pruebas unitarias producto del artículo "¿Qué pasa con mis pruebas unitarias?". Espero que el texto a continuación despeje todas las dudas sobre mi posición al respecto.

Sube el Telón

Software: una palabra que desde hace ya un tiempo ha pasado a formar parte muy importante en la vida de muchas personas a lo largo de todo el mundo. Unos, dependen de él para el cumplimiento normal de sus actividades diarias. Otros, lo tienen como su principal herramienta de trabajo. Algunos, un poco más dichosos, son los responsables de su creación y mantenimiento: hacen el papel de Dios como Creador, o de Madre Naturaleza, no importa como lo prefieran.

La creación de software es una actividad que desde los mismos inicios de la Era Digital ha reclutado en sus filas a miles y miles de personas que persiguen en su tarea un único objetivo: la perfección. Muchas páginas han sido escritas tratando de dar un poco de luz en el camino para lograr programas estables, flexibles, robustos y, nuevamente, perfectos.

Tanto tiempo y – parece mentira – el hombre no ha logrado aún su principal anhelo: conjugar experiencia, destreza y conocimientos para construir un sistema – entiéndase sistema como software – libre de imperfecciones. Un sueño que ha resultado ser un paradigma prácticamente inalcanzable.

Todo creador – o programador, para ir entrando en términos técnicos – respondería tajantemente a la pregunta "¿Tiene problemas tu sistema?" con una rotunda negativa. Basta con modificar dos puntos: uno, el entrevistado; dos, el pronombre posesivo de la interrogante y formularle a un cliente del sistema "¿Tiene problemas su sistema?". Es muy probable que la lista resulte interminable y hasta irrisoria teniendo en cuenta la primera respuesta. Por alguna misteriosa razón, programador y cliente – o usuario, si lo prefiere – alimentan un volcán de diferencias y contradicciones; una batalla ancestral que nadie apoya y todos tenemos.

He tenido la suerte – o la desgracia – de vivir ambas vidas como otros tantos. He tenido respuestas, o mejor dicho, he tenido que responder las dos preguntas de la discordia. Cada una desde un punto de vista diferente, y – paradójicamente –, dando respuestas muy poco diferentes a las anteriores.

Esta posibilidad se ha convertido en inspiración y catalizador para dedicar gran parte de mi tiempo al estudio de diversas prácticas que me permitan acercarme cada vez más al cliente. Todos sabemos que la perfección, o no existe, o es demasiado costosa obtenerla; sin embargo, podemos lograr un producto final que se acerque lo suficiente como para cerrar en cierto modo la brecha que separa ambos mundos.

Primer Acto

De los cientos de técnicas que persiguen nuestro objetivo quisiera referirme no a la más moderna, sino a una de las más poderosas: el Test, o como diríamos los hispano parlantes, la Prueba. Seguramente una palabra tan oída como "calidad" nos haga pensar precisamente en este punto: el producto una vez concluido necesita pasar por una etapa de pruebas hasta tanto su calidad sea certificada.

En todo equipo de desarrollo, desde que se habla de la producción de software como ciencia, existe – o al menos debiera existir – un grupo de profesionales encargados de realizar las pruebas pertinentes al producto en desarrollo, de forma tal que el resultado final se acerque a los parámetros de calidad establecidos o deseados, en dependencia del caso.

Esto no es nuevo en ningún lugar del mundo, ni siquiera en aquellos donde la producción de software es, si no una técnica de último momento, sí una tarea que hace muy poco tiempo es ha comenzado a cobrar auge rápida y firmemente. La técnica de realizar pruebas al producto – en nuestro caso, al software – no tiene nada de novedoso, pero si variamos su forma de aplicación, entonces nos encontraremos en un camino prácticamente inexplorado por cientos de equipos de desarrollo.

Más explícitamente me encuentro hablando de TDD o Test-Driven Development – que en nuestro idioma sería algo así como "Desarrollo Guiado por Pruebas". Lo más sorprendente del TDD es que no incluye prácticamente ninguna idea nueva, sino que combina las prácticas existentes desde el mismo surgimiento de programas y programadores para garantizar un código limpio que funcione correctamente.

El TDD es una disciplina de la cual pueden encontrarse cientos de documentos publicados con solo realizar una consulta en cualquiera de los buscadores de Internet. Digo disciplina y me refiero estrictamente al sentido directo de la palabra: la utilización de TDD requiere por parte de los programadores de la aplicación de un conjunto de prácticas de la forma, dónde y cuándo se requieran. No hay espacios para la improvisación o descontrol. TDD requiere de esfuerzo, conciencia, y – nuevamente – disciplina.

Para comenzar a formar parte de este mundo, un concepto debe cambiar radicalmente: probar un software no es una actividad que se limite al equipo designado para ello, es una tarea de todo programador. Cada persona será la encargada de probar aquellas secciones de código conformadas por ella. Cada sección de código que pueda fallar, debe ser probada.

Sería bueno definir el término probar. No se necesita ser un erudito para concluir que probar un software no es más que ejercitar cada una de las características funcionales del mismo, o técnicamente hablando, cada uno de sus requerimientos para detectar posibles anomalías o fallos – a los cuales comúnmente les damos el nombre de bugs –. Ahora, lo importante cuando hablamos de TDD, es definir precisamente cuáles serán los medios para hacer estas pruebas.

Un rápido estudio bibliográfico resalta dos tipos fundamentales de pruebas: pruebas unitarias o de unidad y pruebas de aceptación. Las primeras tienen su origen en la era anterior a la programación orientada a objetos y nos dicen que las pruebas individuales se concentrarán en unidades sencillas del sistema en vez de en el sistema completo. Las pruebas unitarias serán construidas de forma automatizada y ejecutadas regularmente durante el desarrollo del proyecto.

Las pruebas de aceptación sirven tanto al cliente como al equipo responsable del proyecto como una medida para determinar el progreso del producto en construcción. Estas pruebas serán creadas por los clientes y especificarán la funcionalidad del sistema desde la perspectiva del usuario. Normalmente, estas pruebas serán realizadas a mano y su ejecución estará estrechamente ligada con la conclusión de las etapas de entrega de los diferentes prototipos del producto.

Vamos a concentrarnos fundamentalmente en las pruebas unitarias ya que son las que tienen un mayor sentido desde el punto de vista del desarrollador. Para ello, vamos a recurrir a un ejemplo de código sencillo: la implementación más antigua de una función que determine si un número es primo o no. El código en Java es como sigue:

package com.samples;
 
public class Sample {
    public static boolean isPrime(int number) {
        for (int i = 2; i < number / 2 + 1; i++) {
            if (number % i == 0) {
                return false;
            }
        }
        return true;
    }
}
El ejemplo muestra una clase compuesta por una función estática la cual pretende devolver un valor booleano en dependencia de si el parámetro especificado es un número primo o no. Ahora bien, supongamos que queremos asegurarnos de que la función presente el comportamiento adecuado. Para esto, construimos un pequeño programa con el siguiente código:
package com.samples;
 
public class Main {
    public static void main(String[] args) {
 
        if (!Sample.isPrime(1) || !Sample.isPrime(2)) {
            System.out.println("ERROR");
        }
        else if (Sample.isPrime(4) || Sample.isPrime(6)) {
            System.out.println("ERROR");
        }
        else {
            System.out.println("OK");
        }
    }
}
El código anterior sencillamente ejercitará nuestra función pasando diferentes valores para comprobar que los resultados sean los esperados. En caso de existir alguna anomalía, se imprimirá el mensaje ERROR, mientras que si todo sucede tal y como se espera, la cadena OK aparecerá en pantalla. En pocos minutos hemos logrado construir un código y su correspondiente prueba. Si luego de cualquier cambio que sufra nuestro código ejecutamos su prueba correspondiente, podremos estar seguros si continúa trabajando o se introdujo algún error.

Cuando se desea hacer una prueba para una sección de código determinado, el escenario anterior será suficiente. El problema surge cuando deseamos que cada pieza de código que pueda fallar tenga su correspondiente prueba unitaria – precisamente estamos hablando de TDD –. Entonces necesitaremos mecanismos mucho más organizados y eficientes para clasificar y desarrollar cada una de las pruebas.

Es aquí donde entra en escena el proyecto xUnit. xUnit no es más que una plataforma para la realización de pruebas unitarias en cualquier lenguaje de programación. Existen versiones para casi todos los lenguajes como Java, Smalltalk, Delphi, C#, ASP, PHP, Visual Basic, C++ y Perl por solo mencionar algunos. Cada una de estas versiones cuenta con su propio nombre y diferentes características, pero todos persiguen el mismo objetivo final.

Veamos una prueba del ejemplo anterior haciendo uso de la biblioteca JUnit, diseñada para la construcción y ejecución de pruebas unitarias en lenguaje Java:

package com.samples;
 
import junit.framework.TestCase;
 
public class TestSample
    extends TestCase {
      
    public void testIsPrime() {
        assertTrue(Sample.isPrime(1));
        assertTrue(Sample.isPrime(2));
        assertFalse(Sample.isPrime(4));
        assertFalse(Sample.isPrime(6));
    }
}
Ahora el código resultante es mucho más claro, flexible y fácil de mantener. JUnit – como cualquier buen miembro del proyecto xUnit – nos brinda herramientas muy poderosas para la realización de pruebas unitarias. Si comparamos este código con el ejemplo primeramente visto, caeremos en la cuenta de lo sencillo y claro que puede resultar escribir una prueba unitaria.

Segundo Acto

En un mundo lleno de símbolos, xUnit no podía quedar atrás. La utilización de colores opuestos para representar lo bueno y lo malo ha sido una técnica que ha primado a lo largo de la historia. El verde y el rojo – colores del semáforo con significados obvios – son las luces que xUnit utiliza para su propia interpretación de lo correcto y lo incorrecto. Al ser ejecutadas las pruebas, una barra indicadora tomará el color correspondiente en dependencia de si nuestras pruebas detectan errores o no.

El ejemplo anterior dará como resultado una barra verde, ya que la función producirá correctamente el valor resultante. Veamos ahora otro ejemplo donde la prueba detectará rápidamente un error en el código. Para la realización de este ejemplo, utilizaré el lenguaje C#, tan popular en el mundo entero.

Supongamos que necesitamos crear una función que dados dos valores enteros devuelva la suma de ambos. Un ejemplo bien sencillo, cuya prueba haciendo uso de NUnit – versión xUnit para C# – quedará de la siguiente forma:

using NUnit.Framework;
 
namespace Samples.Test
{
    [TestFixture]
    public class TestCalculator
    {
        [Test]
        public void TestSum()
        {
            Assert.AreEqual(3, Calculator.Sum(1, 2));
        }
    }
}
Teniendo la prueba, podemos ejecutarla y observar – como es lógico – que la barra resultante será roja debido a que ni siquiera hemos implementado el código de la función a probar. Pasemos a implementarla y así lograr que la prueba brinde un resultado satisfactorio al ser ejecutada:
namespace Samples;
 
public class Calculator {
 
    public static int Sum(int number1, int number2)
    {
        return number1 + number1; // Error!
    }
}
Al ejecutar la prueba esta vez, la barra continuará indicando un error en nuestro código. Como ya deben haber notado, deliberadamente he introducido un error en la función, realizando la suma con el primer número solamente, por lo cual el resultado final siempre estará alterado. Si cambiamos el resultado de la función y conformamos adecuadamente la suma, la prueba correrá satisfactoriamente (barra verde). Errores como este en un código bastante complejo pueden tardar varios minutos en ser detectados sin la ayuda de pruebas unitarias.

Algo que me gustaría hacer notar en este punto es la forma de desarrollar el segundo ejemplo. Hemos construido la prueba antes de construir el código que logre que esta pueda ser ejecutada. Este estilo de programación es denominado Test-First Development – algo así como Desarrollo Primero de las Pruebas – y es el más citado por los programadores de TDD.

Tercer Acto

Dado que mi objetivo no es caer en detalles particulares de la plataforma xUnit, y mucho menos en sus variantes JUnit y NUnit, hablemos un poquito más de un conjunto de elementos teóricos imprescindibles, o resumiendo rápidamente en una pregunta ¿por qué debo construir pruebas unitarias?

Mi propio punto de vista – al menos el mismo que logró convencerme cuando aún era bastante escéptico respecto a estas prácticas – pudiera exponerlo en los siguientes cinco puntos:

  1. Permiten detectar errores rápidamente en tiempo de diseño. Contar con un paquete de pruebas permitirá detectar de forma clara y rápida los defectos del código a medida que vayan surgiendo. Esto permitirá reducir considerablemente las horas necesarias de depuración que tanto molestan. El resultado será un producto mucho más robusto y libre de errores.
  2. Brindan la confianza necesaria para realizar modificaciones en el código. ¿Alguna vez ha escuchado la célebre frase "Si funciona no lo toque"?. Apuesto que sí. Ciertamente nada es más cierto, pero yo preferiría – con el perdón del autor – modificar ligeramente la frase a la hora de aplicarla al contexto del que estamos tratando: "Si funciona, y no tiene forma de probar después de los cambios, no lo toque". Un conjunto de pruebas unitarias nos dará el coraje necesario para enfrentar cualquier reestructuración – o simples cambios – en nuestro código fuente. Bastará con ejecutar las pruebas para determinar si la operación resultó o si debemos dar marcha atrás.
  3. Son la fuente de documentación más efectiva de nuestro código. Recuerdo que corría rápidamente hasta el ejemplo en el libro de texto cada vez que enfrentaba un problema cuya solución se me antojaba esquiva. Los ejemplos siempre han sido una herramienta muy poderosa para ganar conocimientos. Precisamente una prueba unitaria no es más que una forma de utilizar nuestro código, un ejemplo ejecutable de cómo explotarlo. Toneladas de documentación escrita pudieran opacarse – y hasta borrarse completamente – con un solo ejemplo.
  4. Escribirlas resulta una tarea bastante divertida. Varios autores coinciden que escribir pruebas unitarias puede resultar una tarea adictiva. Mi propia experiencia es que están en lo cierto. El paso del rojo al verde resulta una experiencia única que bien vale la pena disfrutar.
  5. Cualquier característica de un programa que no tenga una prueba automatizada, simplemente no existe. Este punto, a pesar de ser una cita textual, no podía dejar de incluirlo en el listado. Si algo no se ha probado ¿cómo podemos asegurar que realmente funciona? O mejor aún ¿podemos asegurar que siempre funcionará?
Estas son las fuerzas que han impulsado a tantos a convertir esta práctica como propia. Cada vez se publican más libros y artículos referentes al tema, se realizan conferencias, se imparten seminarios y se emplean los más diversos métodos de educación para llevar el desarrollo de pruebas a cada rincón del mundo del desarrollo de software.

Por último, y unido a todo esto, los entornos modernos de desarrollo visual de lenguajes de programación incluyen herramientas para la realización de pruebas unitarias, o al menos vías simples para integrarlos con las versiones existentes de xUnit. Tales son los casos de Eclipse, JBuilder, Visual Studio .NET, VisualAge, Emacs, etc. Los dos primeros para Java, el tercero para C# / VB.NET, el cuarto para Smalltalk y el último para C++.

Baja el Telón

La programación de pruebas unitarias es una tarea que resultará siempre chocante a cualquier programador en el mundo entero. Increíblemente, los ateos se convierten en fervientes creyentes una vez que experimentan a cabalidad todas sus ventajas. Su realización – mucho más si hablamos de TDD – es una tarea, como ya decía, que requiere mucha constancia y disciplina.

Son muchas las técnicas y trucos que se han escrito para escribir pruebas unitarias efectivas. Son unos cuantos los libros que engrosan los estantes en bibliotecas y librerías hablando de estos temas. No se concibe un programador moderno que no incluya la palabra prueba en su vocabulario.

Es nuestra oportunidad ahora para experimentar algo así. Empezar por lo simple hasta que logremos cada vez más adentrarnos en las más diversas formas de la construcción de pruebas. La práctica sistemática nos convertirá en sus más fieles seguidores. Déles una oportunidad y verá que no se arrepentirá.





Desarrollo guiado por Pruebas y Refactorización

URLOrigen: docs.google.com



Nicolás Kicillof, http://www.dc.uba.ar/people/profesores/nicok, es Profesor
Adjunto del Departamento de Computación de la Facultad de Ciencias Exactas
y Naturales de la Universidad de Buenos Aires, donde dicta la materia
Paradigmas de Lenguajes de Programación. Sus campos de investigación son
la Ingeniería del Software y los lenguajes de programación. Posee una vasta
experiencia profesional liderando equipos de consultoría y desarrollo,
especialmente en plataformas Microsoft.