TOI
Test-Driven Development
(TDD)

Autores

josemanuel.beas@degesys.com

INICIATIVA PRUEBAS DE CALIDAD

Alcobendas, 09/04/2008

Resumen del TOI

SLO ESCRIBIR CDIGOPARA ARREGLARUN TEST QUE FALLA

GRACIAS

Es un proceso

2 : ESCRIBIR CDIGO

3 : REFACTOR

1 : ESCRIBIR UN TEST

Pros y cons de usar TDD

HAY QUE CONTAR CON EL ESFUERZO EXTRA DE HACER Y MANTENER LOS TESTS

SE REDUCE EL COSTE PORQUE SE REDUCEN LOS ERRORES

SE DEFINEN LOS REQUISITOS (NO SE QUEDAN OLVIDADOS EN UN DOCUMENTO)

SE MANTIENEN LOS REQUISITOS (CADA VEZ QUE SE CAMBIA UN REQUISITO HAY QUE CAMBIAR O AADIR AL MENOS UN TEST)

Realmente es ms esfuerzo?

http://blog.objectmentor.com/articles/2007/09/30/why-you-have-time-for-tdd-but-may-not-know-it-yet

Evolucin ideal del proyecto

Evolucin REAL del proyecto

Evolucin del proyecto haciendo TDD + IC

Buena prctica

TDD incluye pruebas unitarias y funcionales automatizadas. Ambas se escriben ANTES que el cdigo que especifican. Las pruebas unitarias se escriben segundos antes, y las pruebas de acpetacin horas o incluso das antes.

Es posible ganar lo mismo haciendo las pruebas DESPUS. Sin embargo, es mucho ms difcil. Las pruebas que se escriben ANTES no estn tan influidas por la implementacin.

Las pruebas de aceptacin ANTES de implementar son especificaciones de lo que debera ser. Las pruebas de aceptacin DESPUS de implementar son frecuentemente especificaciones de lo que es.

http://blog.objectmentor.com/articles/2007/09/30/why-you-have-time-for-tdd-but-may-not-know-it-yet

Buena prctica

http://homepage.mac.com/keithray/blog/2006/11/19#JanesRuleDishWasher

La CALIDAD es el resultado de acciones concretas:

Meticulosidad, procedimientos, metodologa...

Pruebas, pruebas y ms pruebas

Profesionalidad

Buscamos la calidad porque:

El cliente est satisfecho (y un cliente satisfecho es un cliente fiel)

Reducimos costes de mantenimiento (el coste de un error despus de la entrega puede ser del orden de 30 veces ms que de resolverlo durante el desarrollo o 100 veces ms que de resolverlo durante el anlisis).

Arreglar defectos de otro no es divertido

CALIDAD

Calidad

LA CALIDAD ES GRATISPERO TIENE UN COSTE

Acceptance TDD

Acceptance Test-Driven

User Story

DEFINITION OF DONE

STDD = Perspectiva de negocioATDD = STDD

Qu tiene que ver con IC?

Un proceso de Integracin Continua consiste en compilar todo el cdigo y ejecutar los tests.

Si escribimos los tests antes que el cdigo, siempre tendremos un test para cada funcionalidad desarrollada. (No debemos olvidar este principio). Por cierto, slo debemos subir cdigo "hecho-hecho".

LAB-1 : TestFirstChallenge

EJEMPLO PARA INTRODUCIR TDD

PRUEBA DE JUNIORS EN DEGESYS

LAB-1 : TestFirstChallenge

ES FCIL PORQUE NOS DAN LOS TESTS: LO VERDADERAMENTE DIFCIL ES DISEAR LOS TESTS

LAB-2

http://www.xp123.com/xplor/xp0201/index.shtml

http://wiki/index.php/TestFirstChallenge

Poner nfasis en los nombres de los tests.

LAB-2 : MoneyExample

TOMADO DEL LIBRO DE KENT BECK

MULTIMONEDA

LAB-2 : MoneyExample

REQUISITOS:

Si el cambio es 2:1, 5$ + 10 = 10$

5$ * 2 = 10$

LAB-2 (testMultiplication)

@Testpublic void testMultiplication() { Dollar five = new Dollar(5); assertEquals(new Dollar(10), five.times(2));}

5$ * 2 = 10$

Inicialmente no compila, entonces creamos la clase Dollar

Necesitamos un constructor con parmetro int

Necesitamos un mtodo public Dollar times ( int times );

Necesitamos implementar equals

LAB-2 (testEquality)

@Testpublic void testMultiplication() { Dollar five = new Dollar(5); assertEquals(new Dollar(10), five.times(2));}@Testpublic void testEquality() { assertTrue(new Dollar(5).equals(new Dollar(5))); assertFalse(new Dollar(5).equals(new Dollar(6)));}

5$ * 2 = 10$

Podamos implementar equals devolviendo true

LAB-2 (testMultiplication)

@Testpublic void testMultiplication() { Dollar five = new Dollar(5); assertEquals(new Dollar(10), five.times(2)); assertEquals(new Dollar(15), five.times(3));}

5$ * 2 = 10$

Triangulacin: podamos pasar el test devolviendo new Dollar(10)

LAB-2 (testEuroMultiplication)

@Testpublic void testEuroMultiplication() { Euro five = new Euro(5); assertEquals(new Euro(10), five.times(2)); assertEquals(new Euro(15), five.times(3));}

5 * 2 = 10

Aadimos tambin asserts en testEquality por simetra (y porque podramos hacer trampa)

LAB-2 (testEuroMultiplication)

assertFalse(new Euro(5).equals(new Dollar(5)));

5 * 2 = 10

Podemos refactorizar ahora... o no, pero no nos quedar ms remedio cuando aadamos el siguiente assert:

LAB-2 (testSimpleAdditionSameCurrency)

@Testpublic void testSimpleAdditionSameCurrency() { Money sumOfDollars = new Dollar(5).plus(new Dollar(5)); assertEquals(new Dollar(10), sumOfDollars);}

Triangulacin: esto es un ejemplo, pero es una buena prctica aadir tests para evitar a los tahures.

Podemos implementar el mtodo plus() en la clase abstracta, pero sera una mala prctica (habramos desarrollado cdigo sin un requisito que lo respalde, lo que se demuestra cuando aadimos un test y sigue en verde)

5$ + 5$ = 10$

LAB-2 (testBankExchangeRate)

@Testpublic void testBankExchangeRate() { Bank bank = new Bank(); bank.addRate(Euro.class,Dollar.class,new Double(2)); assertEquals(new Double(2), bank.getRate(Euro.class,Dollar.class)); bank.addRate(Euro.class,Dollar.class,new Double(3)); assertEquals(new Double(3), bank.getRate(Euro.class,Dollar.class));}

Necesitamos un colaborador: podemos implementarlo o usar un doble.

Si el cambio es 2:1, 5$ + 10 = 10$

LAB-2 (testBankExchangeRate)

@Testpublic void testBankExchangeEurosToDollars() { Bank bank = new Bank(); bank.addRate(Euro.class,Dollar.class,new Double(2)); Money result = bank.exchange(new Euro(10), Dollar.class); assertEquals(new Dollar(5), result);}

Implementar Bank.exchange implica implementar Money.createInstance

Y EL TEST DE Money.createInstance

Si el cambio es 2:1, 5$ + 10 = 10$

LAB-2 (testSimpleAdditionDifferentCurrency)

@Testpublic void testSimpleAdditionDifferentCurrency() { Bank bank = new Bank(); bank.addRate(Euro.class,Dollar.class,new Double(2)); Money result = bank.exchange(new Euro(10), Dollar.class). plus(new Dollar(5)); assertEquals(new Dollar(10), result); bank.addRate(Dollar.class,Euro.class,new Double(0.5)); result = bank.exchange(new Dollar(5), Euro.class). plus(new Euro(3)); assertEquals(new Euro(13), result);}

Hay que llevar plus(Dollar) y plus(Euro) a la clase Money y luego podremos hacer refactor [Lo dejo como ejercicio]

Si el cambio es 2:1, 5$ + 10 = 10$

Conceptos (I)

FIXTURE

COLABORADORES

Fixture:son el contexto para las pruebas y nos permiten centrarnos en las pruebas

Colaboradores

Dobles de pruebas: (Def del TOI)

Probar el estado / probar las interacciones

Conceptos (II)

DOBLES DE PRUEBAS

PROBAR EL ESTADOvsPROBAR LAS INTERACCIONES

http://fry/dokeos/courses/TOIIPC003 http://flexo/svnRepo/TOI/TOI-DoblesPrueba

Fixture:son el contexto para las pruebas y nos permiten centrarnos en las pruebas

Colaboradores

Dobles de pruebas: (Def del TOI)

Probar el estado / probar las interacciones

Temas relacionados

Cmo disear pensando en las pruebas?

Patrones de pruebas

Cmo hacer TDD con cdigo ya existente?

TDD en diferentes entornos

Web

TOI Mocks en JSF

TOI Selenium

Persistencia

TOI Pruebas de persistencia

Negocio

TOI Pruebas FIT

Aunque los TOIs no se centren en TDD: no olvidemos por qu los tests primero

Bibliografa recomendada

Enlaces

http://www.theserverside.com/tt/articles/article.tss?l=JMockTestDrivenDev http://www.jmock.org/oopsla2004.pdf http://www.theserverside.com/tt/articles/article.tss?l=DesigntoUnitTesthttp://www.ibm.com/developerworks/webservices/library/co-single.html

http://www.testearly.com/http://www.mockobjects.com/http://www.mockobjects.com/labels/listening%20to%20the%20tests.html

GRACIAS

Pulse para editar el formato del texto de ttulo

Pulse para editar los formatos del texto del esquema

Segundo nivel del esquema

Tercer nivel del esquema

Cuarto nivel del esquema

Quinto nivel del esquema

Sexto nivel del esquema

Sptimo nivel del esquema

Octavo nivel del esquema

Noveno nivel del esquema

Pulse para editar el formato del texto de ttulo

Pulse para editar los formatos del texto del esquema

Segundo nivel del esquema

Tercer nivel del esquema

Cuarto nivel del esquema

Quinto nivel del esquema

Sexto nivel del esquema

Sptimo nivel del esquema

Octavo nivel del esquema

Noveno nivel del esquema