Test Driven Development

Presentación del tema: "Test Driven Development"— Transcripción de la presentación:

1 Test Driven Development
Giannina Costa

2 ¿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.

3 ¿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.

4 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.

5 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.

6 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. Cinco principios basicos de la O-O, lo que sirve para cohesión y acoplamiento S: Single responsability O:open/close L:Liskiv Substitution I:Interface segregation D: Dependencia inversion

7 Pasos de TDD 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

8 ¿Qué es TDD? Dos reglas importantes:
Nunca escribir una línea de código a menos que tengamos un test. Los tests representan los requerimientos que el código debe satisfacer, si no hay requerimiento es porque no hay nada que implementar. Eliminar duplicación de código.

9 Codificar - Refactorizar
Dos Objetivos Cuando codificamos, agregamos nueva funcionalidad Cuando refactorizamos, sólo mejoramos el diseño del código. Dos Sombreros Uno para codificar Otro para refactorizar Cuando hacemos que la prueba pase, sólo codificamos.

10 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.

11 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.

12 El proceso de TDD Armar una lista de tests. Esto permite describir los
requerimientos de forma no ambigua e indicar el scope de los mismos. Red Green Refactor El proceso se debe realizar en pasos pequeños lo que permite determinar rápidamente donde cometimos un error en caso de hacerlo.

13 El proceso de TDD 1.- Escribir el código asociado a un test. 2.-Compilar el código asociado al test. (no compila porque aún no se ha implementado) 3.-Implementar sólo lo suficiente para que el código escrito compile. 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

15 Herramientas xUnit (JUnit, NUnit, DbUnit, HttpUnit, etc.) Easy Mock JMock TestNG Selenium

16 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.

17 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 inicial Cuando (When):   Un evento se produce Entonces (Then):  Asegure algunos resultados.

18 BDD (Behavior Driven Development)
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édito Y la tarjeta es válida Y el cajero automático tiene dinero Cuando el cliente pide dinero Entonces, asegurare que la cuenta sea debitada Y asegure que el dinero sea entregado Y asegure que la tarjeta sea devuelta.

19 CUCUMBER

20 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ón Implemente la funcionalidad.

21 ATDD 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 que Se 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 fin de 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

22 ATDD Herramientas ATDD Tucídides Espectacular FitNesse Concordion

23 Relación tdd y atdd

24 Niveles de Pruebas