TEST

DRIVEN

DEVELOPM

ENT

GIANNIN

A COSTA

¿QUÉ ES TDD?

El Desarrollo Dirigido por Tests (Test Driven Development)

Centrada en tres pilares fundamentales: La implementación de las funciones justas que el cliente

necesita y no más. La minimización del número de defectos que llegan al

software en fase de producción. La producción de software modular, altamente

reutilizable y preparado para el cambio.

¿QUÉ ES TDD?

No se trata de escribir pruebas como locos, sino de diseñar

adecuadamente según los requisitos. Pasamos de pensar en implementar tareas, a pensar en

ejemplos

certeros que eliminen la ambigüedades. Con TDD se intenta traducir el requerimiento, hasta que el

número de

ejemplos sea suficiente como para describir la tarea sin lugar a

malinterpretaciones de ningún tipo. En TDD dejamos que la propia implementación de pequeños

ejemplos, en constantes iteraciones, haga emerger la arquitectura quenecesitamos usar.

PASOS DE TDD

1.- Escribir la especificación del requisito (el ejemplo, el test) Una vez que tenemos claro cuál es el requisito, lo

expresamos en forma de código. Pensar primero en cómo queremos que sea la API, es decir,

tenemos que trazar antes de implementar. Tenemos que hacer el esfuerzo de imaginar cómo seria el

código como si ya estuviera implementado y cómo comprobaríamos que, efectivamente, hace lo que le pedimos que haga.

PASOS DE TDD

2.- Implementar el código según dicho ejemplo

Teniendo el ejemplo escrito, codificamos lo mínimo necesario para que se cumpla, para que el test pase.

Lo primordial es no implementar nada más que lo estrictamente obligatorio para cumplir la especificación actual.

Muchas veces vendrán a la mente dudas sobre el comportamiento ante distintas entradas (los distintos flujos condicionales). La solución a esto es anotar las preguntas que nos han surgido en un lugar al margen para convertirlas en especificaciones que se retomaran en posteriores iteraciones.

PASOS DE TDD

3.- Refactorizar para eliminar duplicidad y hacer mejoras.

Según Martín Fowler, refactorizar es "modificar el diseño sin alterar su comportamiento“Rastrear el código (también el del test) en busca de líneas duplicadas y las eliminarlas. Revisar que el código cumpla con ciertos principios de diseño (S.O.L.I.D) y refactorizamos para que así sea.La clave de una buena refactorización es hacerlo en pasitos muy pequeños. Se hace un cambio, se ejecutan todos los tests y, si todo sigue funcionando, se hace otro pequeño cambio.

7

3.- Refactorizar para eliminar duplicidad y hacer mejoras.

• Mejorar el código existente

• Elevar la flexibilidad – tolerancia al cambio

Código Spaghetti vs Código Raviol

Entregar más rápido Menos depuración

PASOS DE TDD

¿QUÉ ES TDD?

Dos reglas importantes:

• Nunca escribir una línea de código a menos quetengamos un test. Los tests representan losrequerimientos que el código debe satisfacer, si no

hayrequerimiento es porque no hay nada que

implementar.

• Eliminar duplicación de código.

9

CODIFICAR - REFACTORIZAR

Dos Sombreros

Uno para codificar

Otro para refactorizar

Dos Objetivos

Cuando codificamos, agregamos nueva funcionalidad

Cuando refactorizamos, sólo mejoramos el diseño del código.

Cuando hacemos que la prueba pase, sólo codificamos.

TDD IMPLICA DISEÑO SIMPLE

Nuestro código debe satisfacer los requerimientos (tests)

ni menos ni más.

Si no escribimos el código necesario para satisfacer los

requerimientos no estamos cumpliendo con lo solicitado,

si escribimos de más agregamos complejidad innecesaria

que luego hay que mantener.

TDD IMPLICA DISEÑO SIMPLE

Guías para lograr ni menos ni más:El código es apropiado para quien está dirigido.

El código pasa todos los tests.El código comunica todo lo necesario.El código tiene la menor cantidad de clases.El código tiene la menor cantidad de métodos.

EL PROCESO DE TDD

Armar una lista de tests. Esto permite describir losrequerimientos de forma no ambigua e indicar el scopede los mismos.• Red• Green• RefactorEl proceso se debe realizar en pasos pequeños lo que

permitedeterminar rápidamente donde cometimos un error en

casode hacerlo.

EL PROCESO DE TDD

1.- Escribir el código asociado a un test.2.-Compilar el código asociado al test. (no compila

porqueaún no se ha implementado)3.-Implementar sólo lo suficiente para que el código

escritocompile.4.- Correr el test y ver si falla.5.- Implementar sólo lo suficiente para que el test pase.6.- Correr el test y ver que efectivamente pasa.7.- Refactorizar para aclarar y eliminar duplicación.8.- Repetir con todos los tests de la lista.

14

BENEFICIOS DE TDD

• No hay código sin pruebas asociadas

• El código se origina y permanece sólido

• Las pruebas perduran

• Las pruebas son documentación

• Efecto psicológico

HERRAMIENTAS

xUnit (JUnit, NUnit, DbUnit, HttpUnit, etc.)

Easy Mock

JMock

TestNG

Selenium

BDD (BEHAVIOR DRIVEN DEVELOPMENT)

El Desarrollo Guiado por el Comportamiento, es un proceso que amplia las ideas de TDD y las combina con diseño de software y análisis de negocio para proporcionar un proceso a los desarrolladores, con la intención de mejorar el desarrollo del software.

En BDD no se prueban solo unidades o clases, se prueban escenarios y el comportamiento de las clases a la hora de cumplir dichos escenarios, los cuales pueden estar compuestos de varias clases.

BDD (BEHAVIOR DRIVEN DEVELOPMENT)

Ayuda a centrarse en lo importante para el negocio.Pueden servir como base a las pruebas de aceptación

BDD usa una plantilla para poder pensar en el comportamiento de las pruebas del código:

En BDD se escriben primero el comportamiento esperado de la aplicación, haciéndolo demostrable y automatizándolo en pruebas de aceptación, lo que se denomina especificación activa.

Dado (Given): Un contexto inicialCuando (When):   Un evento se produceEntonces (Then):  Asegure algunos resultados.

Historia de Usuario“Como un cliente, quiero sacar dinero del cajero automático”

Hay varios escenarios a considerar.:• Que la cuenta tenga saldo.• Que monto un supere el límite de crédito.

Escenario 1: Cuenta tiene crédito

Dado que la cuenta posee créditoY la tarjeta es válidaY el cajero automático tiene dineroCuando el cliente pide dineroEntonces, asegurare que la cuenta sea debitadaY asegure que el dinero sea entregadoY asegure que la tarjeta sea devuelta.

BDD (BEHAVIOR DRIVEN DEVELOPMENT)

CUCUMBER

ATDD

Las pruebas de aceptación son escritas ANTES de la funcionalidad. Siguiendo los siguientes pasos:

Tome una historia de usuario Escriba las pruebas de aceptación en el lenguaje de dominio del cliente Automatice las pruebas de aceptaciónImplemente la funcionalidad.

El ciclo ATDD consta de 4 fases:

1. Discusión: En las reuniones de planeación, se discute las HU que se van abordar y lo queSe espera de cada una de ellas.

2. Destilar:  Una vez se han discutido las pruebas funcionales de aceptación y el comportamiento esperado, se deben capturar en formato de pruebas, para posteriormente ser aplicadas.

3. Desarrollar el código: Se debe abordar el desarrollo del código.

4. Producir un Demo: Con frecuencia se debe integrar el código producido con el finde producir una versión preliminar y aplicarle el set de pruebas diseñado previamente.Si una o varias de las pruebas fallan, se vuelve al proceso de codificación para hacer los ajustes correspondientes

ATDD

Herramientas ATDD TucídidesEspectacularFitNesseConcordion 

ATDD

RELACIÓN TDD Y ATDD

NIVELES DE PRUEBAS