Introducción al Test-Driven Development (TDD) por Eric Mignot

Test-driven development

@EricMinio

Cuando empecé a trabajar...

...asi iban las cosas :

Cuando lo pienso hoy...

...escribíamos la aplicación varias veces :-(







Receta a seguir...

...para tener Éxito (ascender en la compañía):● Seguir los procesos● Dominar las herramientas● Escribir documentos precisos● Negociar el contrato duramente con el cliente● Seguir el plan

No Funcionaba mal...

● Solíamos trabajar durante las noches pero solamente al final del proyecto

● Conseguíamos culpar al cliente de todo● Teníamos éxito financiero gracias al trabajo añadido

después del fin del proyecto

Ah Claro...

● estábamos cansados● estresados● cruzábamos los dedos a cada entrega● ...● pensábamos en serio hacer y vender empanadas (más

fácil, no?) en vez de todo esto

Además...

...nadie tenía la culpa

Además...


Además...


Además...


Es decir...

...era culpa del cliente !

STOP !!!

No tenía sentido

A menudo, hubo un golpe, una chispa...

● algunos leyeron un libro● otros se tomaron una cerveza con amigos● para otros fue la noche que rebasó el límite

Por ejemplo algunos...

...leyeron este libro...

...y lo leyeron de nuevo


...

Otros...

...leyeron este libro...



...

Y mas recientemente...

...este libro...



...

Y hay aquellos...

...quienes tomaron todo esto MUY en serio.

Y hay aquellos...

...quienes tomaron todo esto MUY en serio.

Test-driven development

@EricMinio

Una idea clave

Hacer colaborar las diferentes partes interesadas

Si simplificamos un poco...

...encontramos 3 categorias de partes interesadas● Aquellos que especifican● Aquellos que escriben código● Aquellos que testean

Desafortunadamente, la mayoria del tiempo

● No hablan el mismo idioma● No trabajan juntos● Incluso a veces ni siquiera se conocen

Manos a la obra !

Podemos ayudarlos● a trabajar juntos● a hacer ´til el trabajo de cada uno● a sentirse juntos en esa aventura● A tener placer ?

Buena noticia !

Hemos inventado todo lo que hace falta para eso :-)

Que tal no hablar de "tests"...

● Una especificación evoca un comportamiento● Un test ilustra un ejemplo de utilización● Un test puede ser un programa que ejecuta código

...sino de especificaciones ejecutables

● Contienen ejemplos● Estan ligadas al codigo● Son un lugar de encuentro y de intercambio de ideas

Entónces ? Test o Spec ?

Depende del punto de vista, para qué sirven, a quién

● ¿Se ejecutan para averiguar que todo funciona bien ? -> parecen tests

● ¿Se escriben para describir un comportamiento aún por venir ?

-> parecen especificaciones

Que es Test-Driven Development ?

Elija la definición que le ayude● Especificar comportamientos gracias a ejemplos● Ligar especificaciones y código● Escribir tests antes del código● Intercambiar ideas escribiendo código● Compartir ideas● Hacer que los tests sean las stars de la aventura● Ponerse de acuerdo acerca de nuestra intención● Capitalizar nuestras conversaciones en tests● Documentar como usar un código● Levantarse y pensar en las pruebas por escribir hoy● Acostarse y pensar a las pruebas que pasaron hoy● ...

Van a oír hablar...

...del "ciclo" del TDD

Una primera visión sencilla del ciclo

1 : Test● escribir un test y ver que falla

2 : Code● hacer pasar el test rápidamente

3 : Refactor● no se añade funcionalidad● se mejora la calidad interna

TDD & Calidad

¿Qué es un programa de calidad ?

5 minutos con su vecino

TDD & Calidad

¿Cuál es nuestro compromiso como profesional informático ?

5 minutos más :)

TDD & Calidad

"El modelo emerge durante el refactoring"Durante un curso TDD, los participantes suelen preguntarme

● ¿Tengo que escribir tests para las clases que emergen durante un refactoring ?

● Si lo hago, ¿no estoy quebrando el ciclo ?

¿Qué opinan de esto ?

¿Y si modifico el dibujo asi ?

¿Le recuerda algo ?

¿"Test-Driven Scrum" ?

"Show me the code!"

"Show me the code!"

Merci

Bons tests ! ;-)

Introducción al Test-Driven Development (TDD) por Eric Mignot

Software