Toi Tdd 20080409

TOI Test-Driven Development (TDD) Autores [email_address] INICIATIVA PRUEBAS DE CALIDAD Alcobendas, 09/04/2008

Resumen del TOI “ SÓLO ESCRIBIR CÓDIGO PARA ARREGLAR UN TEST QUE FALLA”

Es un proceso 3 : REFACTOR 2 : ESCRIBIR CÓDIGO 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 AÑADIR AL MENOS UN TEST)

¿Realmente es más esfuerzo? http://blog.objectmentor.com/articles/2007/09/30/why-you-have-time-for-tdd-but-may-not-know-it-yet Evolución ideal del proyecto Evolución REAL del proyecto Evolución del proyecto haciendo TDD + IC

Buena práctica “ TDD incluye pruebas unitarias y funcionales automatizadas. Ambas se escriben ANTES que el código que especifican. Las pruebas unitarias se escriben segundos antes, y las pruebas de acpetación horas o incluso días antes. Es posible ganar lo mismo haciendo las pruebas DESPUÉS. Sin embargo, es mucho más difícil. Las pruebas que se escriben ANTES no están tan influidas por la implementación. Las pruebas de aceptación ANTES de implementar son especificaciones de lo que debería ser. Las pruebas de aceptación DESPUÉS 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 práctica http://homepage.mac.com/keithray/blog/2006/11/19#JanesRuleDishWasher

La CALIDAD es el resultado de acciones concretas: Meticulosidad, procedimientos, metodología... Pruebas, pruebas y más 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 después de la entrega puede ser del orden de 30 veces más que de resolverlo durante el desarrollo o 100 veces más que de resolverlo durante el análisis). Arreglar defectos de otro “no es divertido” CALIDAD

Calidad LA CALIDAD ES GRATIS PERO TIENE UN COSTE

Acceptance TDD Acceptance Test-Driven User Story DEFINITION OF DONE

¿Qué tiene que ver con IC? Un proceso de Integración Continua consiste en compilar todo el código y ejecutar los tests. Si escribimos los tests antes que el código , siempre tendremos un test para cada funcionalidad desarrollada. (No debemos olvidar este principio). Por cierto, sólo debemos subir código "hecho-hecho" .

LAB-1 : TestFirstChallenge EJEMPLO PARA INTRODUCIR TDD PRUEBA DE JUNIORS EN DEGESYS

LAB-1 : TestFirstChallenge ES FÁCIL PORQUE NOS DAN LOS TESTS: LO VERDADERAMENTE DIFÍCIL ES DISEÑAR LOS TESTS LAB-2 http://www.xp123.com/xplor/xp0201/index.shtml http://wiki/index.php/TestFirstChallenge

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) @Test public 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 parámetro int Necesitamos un método public Dollar times ( int times ); Necesitamos implementar equals

LAB-2 (testEquality) @Test public void testMultiplication() { Dollar five = new Dollar(5); assertEquals ( new Dollar(10), five.times(2)); } @Test public void testEquality() { assertTrue ( new Dollar(5).equals( new Dollar(5))); assertFalse ( new Dollar(5).equals( new Dollar(6))); } 5$ * 2 = 10$ Podíamos implementar equals devolviendo true

LAB-2 (testMultiplication) @Test public void testMultiplication() { Dollar five = new Dollar(5); assertEquals ( new Dollar(10), five.times(2)); assertEquals ( new Dollar(15), five.times(3)); } 5$ * 2 = 10$ Triangulación: podíamos pasar el test devolviendo new Dollar(10)

LAB-2 (testEuroMultiplication) @Test public void testEuroMultiplication() { Euro five = new Euro(5); assertEquals ( new Euro(10), five.times(2)); assertEquals ( new Euro(15), five.times(3)); } 5 € * 2 = 10 € Añadimos también asserts en testEquality por simetría (y porque podríamos 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á más remedio cuando añadamos el siguiente assert:

LAB-2 (testSimpleAdditionSameCurrency) @Test public void testSimpleAdditionSameCurrency() { Money sumOfDollars = new Dollar(5).plus( new Dollar(5)); assertEquals ( new Dollar(10), sumOfDollars); } Triangulación: esto es un ejemplo, pero es una buena práctica añadir tests para evitar a los “tahures”. Podemos implementar el método plus() en la clase abstracta, pero sería una mala práctica (habríamos desarrollado código sin un requisito que lo respalde, lo que se demuestra cuando añadimos un test y sigue en verde ) 5$ + 5$ = 10$

LAB-2 (testBankExchangeRate) @Test public 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) @Test public 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) @Test public 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

Conceptos (II) DOBLES DE PRUEBAS PROBAR EL ESTADO vs PROBAR LAS INTERACCIONES http://fry/dokeos/courses/TOIIPC003 http://flexo/svnRepo/TOI/TOI-DoblesPrueba

Temas relacionados ¿Cómo diseñar pensando en las pruebas? Patrones de pruebas ¿Cómo hacer TDD con código 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”

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=DesigntoUnitTest http://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

Toi Tdd 20080409

Más contenido relacionado

Similar a Toi Tdd 20080409 (20)

Más de Jose Manuel Beas (20)

Último (20)

Toi Tdd 20080409