Taller Test Driven Development

Slide 1: Taller de Test Driven Development Introducci´n o Pablo Ordu˜a (aka NcTrun) n Test Driven . . . Con la colaboraci´n de Iker Larizgoitia o Continuous Integration Conclusiones Referencias P´gina www a P´gina de Abertura a P´gina 1 de 23 a This work is licensed under the Creative Commons Attribution-ShareAlike License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.0/ or send a letter to Creative Commons, 559 Regresar Nathan Abbott Way, Stanford, California 94305, USA Full Screen Cerrar Abandonar

Slide 2: 1. Introducci´n o 1.1. ¿De qu´ va este taller? e • Es un taller pr´ctico a Introducci´n o Test Driven . . . – Aunque hay “un poquillo” de chapa al principio ;-) Continuous Integration • Es un taller de Test Driven Development Conclusiones Referencias ıas ´ – Pero enmarcado dentro de una muy breve introducci´n de Metodolog´ Agiles de Desarrollo o – No es “un taller de JUnit” P´gina www a • Pero, sobre todo, es un taller informal P´gina de Abertura a – Es la primera vez que doy algo de esto – Tengo muy poca experiencia en el tema – Me encantar´ oir “pero”s a lo que voy a explicar ıa • Conclusi´n → por favor, participad ;-) o P´gina 2 de 23 a Regresar Full Screen Cerrar Abandonar

Slide 3: 1.2. ´ Metodolog´ de desarrollo Agil ıas 1.2.1. Metodolog´ de desarrollo tradicionales ıas • Tradicionalmente: Introducci´n o – Se compara el desarrollo de software con la construcci´n de edificios o Test Driven . . . ∗ Las fases de codificaci´n y pruebas parecen algo “mec´nico” o a Continuous Integration Conclusiones – Nos centramos unicamente en arquitecturas, requisitos, dise˜o. . . ´ n Referencias ∗ Programar → tarea “de bajo nivel” ∗ Dise˜o → tarea que no necesita experiencia en programaci´n n o P´gina www a – Modelo en cascada P´gina de Abertura a ∗ Pocas iteraciones, y muy grandes, que cada una incluye: 1. An´lisis a 2. Dise˜o n 3. Implementaci´n o 4. Pruebas – Producir cambios en las fases de implementaci´n y pruebas sugiere un mal dise˜o o planifi- o n P´gina 3 de 23 a caci´n o ∗ Se barajan peque˜as tasas de cambio aceptables n Regresar · lo que est´ fuera por tanto ser´ ¿inaceptable? e a ∗ Nos frustramos cuando tenemos que cambiar el dise˜o de nuestras aplicaciones n Full Screen · Pensamos que se ha hecho mal el dise˜o (lo hayamos hecho nosotros u otros) n · Nos da miedo modificar c´digo que hace meses que no tocamos o Cerrar · Pensamos que hemos hecho mal en no haber documentado al detalle este c´digo que o ahora nos da miedo modificar Abandonar

Slide 4: – Una pesada integraci´n sugiere un mal dise˜o o n ∗ Damos por hecho que sin un dise˜o detallado de todo, la integraci´n ser´ un poco caos n o a ∗ A veces se convierte en un proceso pesado, impredecible, que no sabemos qu´ impacto e tendr´ a Introducci´n o • Y sin embargo. . . funciona: Test Driven . . . Continuous Integration – En gran cantidad de proyectos en los que esta forma de trabajar funcionar´: a Conclusiones ∗ Dependiendo de si la tecnolog´ es bien conocida por el equipo ıa Referencias ∗ Dependiendo de cu´nto de cambiante sea la tecnolog´ a ıa P´gina www a ∗ Dependiendo del tama˜o del equipo n ∗ Dependiendo de la formaci´n del equipo o P´gina de Abertura a ∗ Dependiendo de si tenemos competencia directa o no ∗ Dependiendo de la dedicaci´n del equipo (m´s proyectos?) o a ∗ Dependiendo de muchos m´s factores. . . a P´gina 4 de 23 a Regresar Full Screen Cerrar Abandonar

Slide 5: 1.2.2. Metodolog´ de desarrollo ´gil ıas a • Pero no todo son clavos para nuestro martillo: – Existen situaciones que pueden dar problemas: Introducci´n o ∗ Competidores que desarrollan el mismo software para los mismos clientes → tendremos Test Driven . . . que adaptarnos r´pidamente para ofrecer las mismas caracter´ a ısticas. . . Continuous Integration · Una metodolog´ en la que tenemos que terminar la larga iteraci´n actual para obtener ıa o Conclusiones estos nuevos requisitos, y en el que no ofreceremos resultados hasta terminar la Referencias siguiente larga iteraci´n puede no ser adecuado o ∗ Si utilizamos tecnolog´ que cambian mucho, o en el que salen nuevas cada poco tiempo, ıas P´gina www a y que afectar´ muy positivamente a nuestro proyecto si nos adapt´semos a ellas, o que ıa a incluso no adaptarnos nos penalizar´ . . ıa. P´gina de Abertura a · Una metodolog´ que critica el cambio o propone esperar hasta la siguiente iteraci´n ıa o para adaptarlas puede no ser adecuado ∗ Si el proyecto tiene un unico cliente y entiende el riesgo que hay en no ofrecer resultados ´ hasta pasados a˜os. . . n · Una metodolog´ que unicamente conf´ en las grandes iteraciones puede no ser ıa ´ ıa adecuado, frente a una que proponga muchas peque˜as iteraciones que vayan poco n P´gina 5 de 23 a a poco adapt´ndose a los requisitos del cliente, y aceptando los cambios que vaya a proponiendo Regresar – En general, en proyectos exploratorios, las metodolog´ de desarrollo rigurosas pueden pre- ıas sentar graves problemas Full Screen ∗ Proyectos exploratorios → Exploratory projects are frontier (research-like), mission critical, time driven, and constantly changing (Jim Highsmith, Agile Software Development Ecosystems, 2002). ∗ Las metodolog´ rigurosas pueden intentar adaptarse a estas situaciones proponiendo dise˜os m´s generales ıas n a Cerrar · Suficientemente general para cambios que no conocemos en la fase de dise˜o n · Terminamos generando mucho m´s software del que necesitamos → necesitando m´s tiempo para desarrollar cosas que nunca se usar´n (bloatware) a a a · Si las iteraciones se mantienen grandes, hay situaciones ante las que no podr´n responder a Abandonar

Slide 6: • Dando la vuelta a la tortilla: – Si el cambio no es tan malo en muchas situaciones → ¿Por qu´ no aprovecharnos de ´l? e e ∗ Si fu´semos capaces de adaptarnos r´pidamente a nuevos cambios seg´n llegan nuevas e a u oportunidades. . . Introducci´n o · ¿Podr´n nuestros competidores adaptarse a nuestros cambios? a Test Driven . . . Continuous Integration · ¿Por qu´ no ofrecemos versiones peri´dicas a nuestros clientes y nos adaptamos a e o Conclusiones los cambios que ellos vayan deseando? ¿No se ajustar´ mejor el resultado final a lo a deseado por el cliente? Referencias Explicando claramente cu´l es el impacto de los cambios que el cliente desea a P´gina www a ´ – Metodolog´ de Desarrollo Agil ıas ∗ Conjunto de metodolog´ que buscan otras formas de desarrollar software: ıas P´gina de Abertura a · Proponen iteraciones cortas (de una a cuatro semanas dependiendo de la metodolog´ ıa) · Proponen diferentes t´cnicas dependiendo de la tecnolog´ e ıa ∗ Sus valores de fondo se transmiten a trav´s del Agile Manifesto http://agilemanifesto. e org/: · Firmado en 2001 por sus fundadores ∗ Encontramos varias formas: P´gina 6 de 23 a · Extreme Programming (XP) · Scrum Regresar · Adaptive Software Development · Feature Driven Development Full Screen · ... Cerrar • Pero sin pasarnos: – No hay una bala de plata o martillo de oro que nos vaya a servir en todas las ocasiones Abandonar

Slide 7: – La soluci´n que tomemos depender´ de muchos factores: o a ∗ Lo que funcion´ en una empresa no tiene por qu´ funcionar en otra o e ∗ Lo que funcion´ en un grupo no tiene por qu´ funcionar en otro o e – Y recordemos que yo ni tengo experiencia ni nada para juzgar nada de esto 0:-D Introducci´n o Test Driven . . . Continuous Integration Conclusiones Referencias P´gina www a P´gina de Abertura a P´gina 7 de 23 a Regresar Full Screen Cerrar Abandonar

Slide 8: • Espera. . . ¿de qu´ dec´ que iba este taller? e ıas – Quiero que el taller sea pr´ctico → no quiero centrarme en metodolog´ de desarrollo ´gil, a ıas a sino en dos pr´cticas (Test Driven Development y Continuous Integration) de una de las a metodolog´ de desarrollo ´gil m´s popular (Extreme Programming) ıas a a Introducci´n o – Sin embargo, me parece imprescindible explicar -aunque haya sido brevemente- qu´ valores y e Test Driven . . . qu´ principios est´n detr´s de estas pr´cticas e a a a Continuous Integration Conclusiones Referencias P´gina www a P´gina de Abertura a P´gina 8 de 23 a Regresar Full Screen Cerrar Abandonar

Slide 9: 2. Test Driven Development 2.1. ¿Qu´ es? e • Test Driven Development es: Introducci´n o Test Driven . . . – Como hemos explicado, una pr´ctica de al menos una metodolog´ de desarrollo ´gil, Extreme a ıa a Continuous Integration Programming Conclusiones – Consiste en desarrollar guiado por pruebas Referencias ∗ Bajo iteraciones cortas tal que: 1. Creamos un test que exige una nueva funcionalidad o caracter´ ıstica P´gina www a 2. Ejecutamos los tests y vemos que ese test falla (luz roja) 3. A˜adimos c´digo que haga que funcione n o P´gina de Abertura a 4. Ejecutamos los tests y vemos que los tests funcionan (luz verde) 5. Refactorizamos nuestro c´digo o • Ejemplo r´pido: codigo/01 Acumulador. a P´gina 9 de 23 a Regresar Full Screen Cerrar Abandonar

Slide 10: Introducci´n o Test Driven . . . Continuous Integration Conclusiones Referencias P´gina www a P´gina de Abertura a P´gina 10 de 23 a Regresar Full Screen Cerrar Abandonar

Slide 11: 2.1.1. Motivaci´n o • ¿Hacer pruebas antes del c´digo? ¿Para qu´? o e – Dise˜o desacoplado → dif´ de dise˜ar c´digo acoplado si primero est´s haciendo el test de n ıcil n o a Introducci´n o cada unidad Test Driven . . . – Confiamos m´s en nosotros mismos → vemos que nuestro c´digo hace lo que decimos que a o Continuous Integration haga Conclusiones – Podemos refactorizar mejor → nos atrevemos a probar diferentes dise˜os sin miedo a romper n Referencias algo ∗ Si rompi´semos algo, alg´n test nos avisar´ e u ıa P´gina www a ∗ Unido a gestores de control de versiones, no dudamos ∗ Incluso podemos hacerlo pasados meses desde que hicimos el c´digo! o P´gina de Abertura a – En todo momento podemos tener una idea del estado del proyecto • ¿Cu´nto hacer? a – ¿Cu´nto es demasiado testing? Pregunta con trampa → ¿Cu´nto es demasiado buen dise˜o? a a n ∗ Obviamente podemos estar gastando demasiado dinero o demasiado tiempo en testing P´gina 11 de 23 a ∗ Hay formas de detectar que hemos hecho suficientes pruebas para una funci´n concreta o ∗ Pero eso no significa que estemos probando demasiado Regresar • ¿Y de qu´ me sirve maximizar la cantidad de c´digo testeado? e o Full Screen – ¿Funcionar´ mi c´digo con esta nueva versi´n de este runtime? ¿Y en esta nueva plataforma? a o o ¿Y con esta nueva versi´n de la librer´ → lanza tus tests y compru´balo o ıa? e Cerrar – Documentaci´n del c´digo → los tests definen qu´ hace el c´digo funcional (no c´mo). o o e o o Manteni´ndolos actualizados, son una documentaci´n muy valiosa de cada funci´n. e o o Abandonar

Slide 12: – Cazar fallos → cuesta m´s arreglar un fallo de c´digo que hicimos ayer que arreglar un fallo a o de c´digo que acabas de hacer. o • Refactorizando c´digo o Introducci´n o – Refactorizar → Mejorar el dise˜o de c´digo existente n o Test Driven . . . ∗ ¿Pero eso no lo hace el IDE? Continuous Integration · Los entornos de desarrollo cuentan con funcionalidades que permiten realizar refac- Conclusiones torizaciones autom´ticamente a Referencias Extraer m´todo, clase, renombrar m´todo/clase/atributo/variable, mover estruc- e e turas o funcionalidades en una jerarqu´ de clases. . . ıa P´gina www a · Sin embargo la refactorizaci´n va m´s all´ → no siempre automatizable o a a ∗ ¿Qu´ tiene que ver el tener tests para refactorizar c´digo? e o P´gina de Abertura a · Si tienes tests que cubren todo tu c´digo → refactorizas m´s f´cil y r´pidamente o a a a · Si no tienes tests que cubren todo tu c´digo → riesgo o ¿Cu´ntas veces hemos o´ si funciona, no lo toques? a ıdo – Comparaci´n: codigo/02 RefactoringInicial y codigo/03 RefactoringFinal. o P´gina 12 de 23 a Regresar Full Screen Cerrar Abandonar

Slide 13: 2.2. Introducci´n a JUnit o • xUnit – Muchas plataformas de pruebas unitarias utilizan una arquitectura denominada xUnit Introducci´n o ∗ Primera implementaci´n → SUnit (Smalltalk), por Kent Beck (cocreador de Extreme o Test Driven . . . Programming) Continuous Integration – Esta arquitectura informal define una serie de m´todos y estructuras que cada implementaci´n e o Conclusiones de cada lenguaje adapta al lenguaje Referencias ∗ JUnit para Java ∗ csUnit y NUnit para .NET P´gina www a ∗ PyUnit para Python P´gina de Abertura a ∗ Y muchos m´s. . . a – Relaci´n con Test Driven Development: o ∗ Test Driven Development utiliza plataformas de pruebas unitarias ∗ Algunas de estas plataformas son compatibles con xUnit ∗ Test Driven Development podr´ utilizar otras plataformas → aplicar TDD no exige utilizar ıa xUnit P´gina 13 de 23 a ∗ Y se puede utilizar xUnit sin utilizar s´lo para hacer pruebas → utilizar xUnit no es aplicar o TDD Regresar • JUnit Full Screen – Conceptos b´sicos: a ∗ Test Fixtures → Precondiciones que un test necesita Cerrar · Tendremos un m´todo setUp que inicialice estas precondiciones e En JUnit 4 → basta con anotarlo con Before Abandonar

Slide 14: · Tendremos un m´todo tearDown que limpie lo que se ha creado en los tests e En JUnit 4 → basta con anotarlo con After ∗ Test Suites → Conjunto de tests que tienen el mismo Test Fixture y comparten una l´gica o com´nu Introducci´n o · Tendremos una clase que tendr´ su Test Fixture y sus tests a Test Driven . . . En JUnit anterior a 4, esta clase heredaba de TestCase Continuous Integration ∗ Tests → Los tests en s´ lanzan los m´todos que se est´n comprobando, y se comprueban ı, e a Conclusiones los resultados Referencias · Anotados con @Test en JUnit 4, normalmente empiezan por test. . . · Se comprueba con diferentes asertos (m´todos est´ticos de la clase Assert en JUnit e a P´gina www a 4) assertEquals(expected, actual), assertTrue(condition), (expected=EjemploException.class). . . P´gina de Abertura a – Ejemplo: 01 Acumulador – Ejercicio: 04 Calculadora P´gina 14 de 23 a Regresar Full Screen Cerrar Abandonar

Slide 15: 2.3. Pr´ctica a • Practicando un poco m´s: 05 BinarySearch a – Recordemos: luz roja, luz verde, refactorizar Introducci´n o – No tenemos por qu´ hacer la mejor soluci´n a la primera :-) e o Test Driven . . . • Y otro poco m´s: a Continuous Integration Conclusiones – Utilizando librer´ externas: 06 LibreriaExterna ıas Referencias – Tenemos una librer´ eterna llamada LibreriaPuertoSerie: ıa P´gina www a ∗ Queremos testear la funcionalidad de la clase UsandoLibreriaExterna ∗ Esta clase depende de LibreriaPuertoSerie P´gina de Abertura a ∗ ¿C´mo testeamos esta funcionalidad? o ∗ Soluci´n en 07 LibreriaExternaSolucion o • Problemas normales a la hora de testear: – C´digo viejo: o ∗ Al testear c´digo que no est´ desarrollado con tests en mente, es com´n encontrar c´digo o a u o P´gina 15 de 23 a muy acoplado, que es dif´ de testear ıcil ∗ Casi sin darnos cuenta, vemos enseguida resultados al comparar c´mo nos queda ahora o Regresar el c´digo y c´mo nos quedaba antes o o – Capas que puede costar testear: Full Screen ∗ GUIs. . . ∗ Objetos remotos. . . Cerrar ∗ Bases de datos. . . ∗ Threading. . . Abandonar

Slide 16: – Ejemplo: aplicaci´n que tiene un interfaz de usuario y finalmente utiliza bases de datos y o hardware ∗ Podr´ıamos por ejemplo hacer tests unitarios de cada parte del proyecto · Wrapeando la parte de m´s bajo nivel (que tenga relaci´n directa con hardware) a o Introducci´n o · Dise˜ando todo el interfaz de usuario encima de un Service Layer, y testeando todos n Test Driven . . . los m´dulos desde Service Layer abajo o Continuous Integration ∗ Luego, hacemos tests de integraci´n o Conclusiones · No comprueban todo, sino la comunicaci´n entre los interfaces de los diferentes ob- o Referencias jetos · Pueden hablar desde arriba del todo (ServiceLayer) hasta abajo del todo (wrapeando P´gina www a una vez m´s el hardware) a ∗ Si el GUI se apoya sobre un Service Layer testeado, no deber´ costar mucho probar ıa P´gina de Abertura a “manualmente” el GUI, que es lo unico que no se ha comprobado ´ P´gina 16 de 23 a Regresar Full Screen Cerrar Abandonar

Slide 17: 3. Continuous Integration 3.1. ¿Qu´ es? e • ¿Qu´ es Continuous Integration? e Introducci´n o Test Driven . . . – Otra pr´ctica de Extreme Programming a Continuous Integration – Esencia: Conclusiones ∗ Trasladar el proceso de integraci´n de software al d´ a d´ antes que relegarlo a una etapa o ıa ıa Referencias final del proyecto ∗ Corregir problemas cuanto antes: P´gina www a · IDEs → Compilaci´n continua → estamos c´modos o o · Sin embargo, con integraci´n → tendemos a dejarla para el final del proyecto con o P´gina de Abertura a todo el riesgo que ello conlleva. Cuando los fallos que se intenten reparar van a ser dif´ ıciles de reparar con la seguridad de no estar rompiendo otras partes del proyecto. ∗ Objetivo → conseguir que todo el c´digo (o casi todo) est´ integrado en todo momento o e – ¿C´mo? o ∗ Contar con un sistema de control de versiones que sea utilizado a diario por todos los P´gina 17 de 23 a desarrolladores ∗ Este sistema de control de versiones deber´ tener absolutamente todo lo necesario para ıa Regresar construir el proyecto · C´digo o Full Screen · Scripts de compilaci´n o · Tests Cerrar · Librer´ externas ıas ∗ Contar con scripts de compilaci´n continuamente actualizados o Abandonar

Slide 18: · Compile todo el proyecto autom´ticamente a · Despliegue todo el proyecto autom´ticamente a · Cualquiera podr´ bajarse el proyecto del repositorio en un momento dado y compilar a y probar todo el software Introducci´n o ∗ Para que sea m´s eficaz → tests a Test Driven . . . · Automatizados Continuous Integration · Lanzados por los scripts de compilaci´n o Conclusiones ∗ Llevar a cabo el proceso de descarga, compilaci´n, despliegue y pruebas a menudo o Referencias · Idealmente → por cada versi´n nueva, llevar a cabo el proceso o · Este proceso se puede automatizar con herramientas de Integraci´n Continua o P´gina www a Ejemplo: CruiseControl P´gina de Abertura a P´gina 18 de 23 a Regresar Full Screen Cerrar Abandonar

Slide 19: 3.2. CruiseControl • ¿Qu´ es CruiseControl? e – Herramienta de Integraci´n Continua :-) o Introducci´n o – Idea → lanza todo el proyecto cada cierto tiempo Test Driven . . . – Muy configurable: Continuous Integration ∗ Los tests unitarios se suelen ejecutar en poco tiempo, mientras que los tests de integraci´n o Conclusiones (que utilizan BD reales, redes reales. . . ), pueden tardar incluso un par de horas. Referencias ∗ CruiseControl permite automatizar que se lancen los tests unitarios cada pocos minutos, mientras que los tests de integraci´n los podr´ lanzar una vez al d´ o ıa ıa P´gina www a ∗ Informa a determinados usuarios de los resultados P´gina de Abertura a · Eliges a qu´ usuarios informar de qu´ resultados e e · Eliges c´mo notificarlo (e-mail, chat a trav´s de jabber, X10 para luces. . . ) o e • Ejemplo pr´ctico a P´gina 19 de 23 a Regresar Full Screen Cerrar Abandonar

Slide 20: 4. Conclusiones Vosotros dir´is :-D e Introducci´n o Test Driven . . . Continuous Integration Conclusiones Referencias P´gina www a P´gina de Abertura a P´gina 20 de 23 a Regresar Full Screen Cerrar Abandonar

Slide 21: 5. Referencias 5.1. Agile Software Development • Agile Software Development Ecosystems. Jim Highsmith. Addison Wesley. Introducci´n o Test Driven . . . • Extreme Programming Explained: Embrace Change, 2nd Edition. Kent Beck. Addison Wesley. Continuous Integration • http://www.extremeprogramming.org/ Conclusiones Referencias 5.2. Test Driven Development P´gina www a • Test Driven Development by Example. Kent Beck. Addison Wesley. • Refactoring: Improving the Design of Existing Code. Martin Fowler. Addison Wesley. P´gina de Abertura a • “Mocks aren’t stubs”. Martin Fowler. http://www.martinfowler.com/articles/mocksArentStubs. html 2007. • “Mock Roles, Not Objects”. Steve Freeman et al. http://www.mockobjects.com/files/ mockrolesnotobjects.pdf 2004. P´gina 21 de 23 a • http://www.junit.org/ Regresar 5.3. Continuous Integration • “Continuous Integration”. Martin Fowler. http://www.martinfowler.com/articles/continuousIntegration. Full Screen html 2006. Cerrar • “Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Applications”. Mike Clark. The Pragmatic Programmers. 2004. Abandonar

Slide 22: • Continuous Integration: Improving Software Quality and Reducing Risk. Paul M. Duvall. Addison Wesley. • http://cruisecontrol.sourceforge.net/ Introducci´n o Test Driven . . . Continuous Integration Conclusiones Referencias P´gina www a P´gina de Abertura a P´gina 22 de 23 a Regresar Full Screen Cerrar Abandonar

Slide 23: Este documento est´ escrito por Pablo Ordu˜a con la colaboraci´n de Iker Larizgoitia para el “Taller a n o de Test Driven Development” del grupo de software libre de la Universidad de Deusto, el e-ghost. Puede A encontrarse junto con los ejemplos y las fuentes LTEXen la misma web. Introducci´n o Para cualquier correcci´n, sugerencia, o comentario en general, no dudes en ponerte en contacto con o Test Driven . . . nosotros en: Continuous Integration Conclusiones Pablo → pablo @ ordunya . com Referencias Iker → ilarizgo @ tecnologico . deusto . es P´gina www a P´gina de Abertura a P´gina 23 de 23 a Regresar Full Screen Cerrar Abandonar