Test Driven Development in Action

Nació como una de las prácticas de eXtreme Programming:

• Actualmente ya es una metodología de desarrollo independiente.
• Se está impartiendo como una metodología aislada de XP.
• Ya se encuentra incluida como parte de otras metodologías más genéricas:
• Rational Unified Process (RUP)
• Agile Unified Process (AUP)
• Open Unified Procress (Open UP)
• SCRUM
  (Bahit, s.f.)

Test Driven Development es principalmente una metodología de desarrollo de software. La misión principal de TDD es dirigir la arquitectura, el diseño y la codificación del software. Sólo se implementa la funcionalidad necesaria, programando siempre el “ahora” y nunca el “mañana” (YAGNI). Dirigir desde el código la arquitectura, diseño y codificación. Minimizar el número de defectos que llegan a los tests de más alto nivel o a la plataforma de producción. Producir software modular, altamente reutilizable y preparado para el cambio. (ITS)

Tests en TDD

Tests de sistema. Ejercitan el sistema desde los extremos (end-to-end). Entran por la interfaz del usuario final y llegan hasta el extremo opuesto. Se ejecutan en la plataforma de preproducción.
Tests de integración. Ejercitan varias unidades del sistema de forma conjunta, verificando la correcta colaboración entre dependencias. Se ejecutan en la plataforma de pre-producción. Múltiples combinaciones según las colaboraciones implicadas.
La frontera que transforma test unitarios en integración a veces es difusa.
Algunos test de integración se pueden usar en las iteraciones TDD (test de integración a pequeña escala).
Tests unitarios. Ejercitan una unidad de código de forma aislada. Un test = un caso o ejemplo de uso de un método o función. Se compilan y se enlazan con el código funcional. Se ejecutan en el equipo de cada desarrollador. Pertenecen a los desarrolladores (usando TDD no hay otra opción).
A veces no es claro cual debería ser el nivel de aislamiento.
Entre otros tipos como: De aceptación o de cliente, De interfaz de usuario, De aceptación vs Interfaz de usuario, Funcionales y No funcionales.

eXtreme programming

eXtreme Programming (programación extrema) también llamado XP, es una metodología que tiene su origen en 1996, de la mano de Kent Beck, Ward Cunningham y Ron Jeffries. A diferencia de Scrum, XP propone solo un conjunto de prácticas técnicas, que aplicadas de manera simultánea, pretenden enfatizar los efectos positivos de en un proyecto de desarrollo de Software. (Bahit, s.f.)
Se apoya en cinco valores, los cuales enfatizan la esencia colaborativa del equipo. Estos valores son:

• Comunicación
• Simplicidad
• Retroalimentación
• Respeto
• Coraje

Comunicación

En XP, todo es trabajado en equipo: desde el relevamiento y análisis hasta el código fuente desarrollado. Todo se conversa cara a cara, procurando hallar soluciones en conjunto a los problemas que puedan surgir. (Bahit, s.f.)

Simplicidad

Se pretende desarrollar solo lo necesario y no perder tiempo en detalles que no sean requeridos en el momento. En este aspecto, se asemeja a otra metodología ágil, denominada Kanban, en la cual, un proceso “anterior” solo produce lo que el proceso posterior demanda. (Bahit, s.f.)

Retroalimentación

El objetivo de eXtreme Programming es entregar lo necesario al cliente, en el menor tiempo posible. A
cambio, demanda al cliente, un feedback continuo -retroalimentación-, a fin de conocer sus requerimientos e implementar los cambios tan pronto como sea posible. (Bahit, s.f.)

Respeto

El equipo respeta la idoneidad del cliente como tal (sólo éste, es quien conoce el valor para el negocio) y el cliente , a la vez, respeta la idoneidad del equipo (confiando en ellos profesionalmente para definir y
decidir el “cómo” se llevará a cabo el desarrollo de lo requerido). (Bahit, s.f.)

Coraje

Se dice que en XP un equipo debe tener el valor para decir la verdad sobre el avance del proyecto y las estimaciones del mismo, planificando el éxito en vez de buscar excusas sobre los errores. (Bahit, s.f.)

Pair Programming

Se estila (aunque no de forma constante) programar en parejas de dos desarrolladores, los cuales podrán ir intercambiando su rol, en las sucesivas Pair Programming. Consiste en dos programadores, sentados frente a una misma computadora, cada uno cumpliendo un rol diferente. Las combinaciones y características de este rol, no solo son variables, sino que además, son inmensas, permitiendo la
libertad de “ser originalmente creativos”. (Bahit, s.f.)