Please enable JavaScript.

Coggle requires JavaScript to display documents.

Desarrollo Guiado por Pruebas - Coggle Diagram

- - - - No es que nos despreocupemos por completo de las características técnicas de la aplicación a priori, es decir, lógicamente tendremos que saber si el desarrollo será para un teléfono móvil, para una web o para un pc de escritorio
      - nos limitamos a escoger el framework correspondiente y a usar su arquitectura como base. Por ejemplo, si escogiésemos Django o ASP.NET MVC7, ya tendríamos definida buena parte de la base antes de empezar a escribir una sola línea de código. No es que trabajemos sin arquitectura, lógicamente, si en los requisitos está la interoperabilidad en las comunicaciones, tendremos que usar servicios web o servicios REST, lo cual ya propicia un determinado soporte.
      - En TDD dejamos que la propia implementación de pequeños ejemplos, en constantes iteraciones, haga emerger la arquitectura que necesitamos usar. Ni más ni menos.
  - - - La calidad del software aumenta (y veremos por qué).
      - Conseguimos código altamente reutilizable.
      - El trabajo en equipo se hace más fácil, une a las personas. Nos permite confiar en nuestros compañeros aunque tengan menos experiencia.
      - Multiplica la comunicación entre los miembros del equipo.
      - Las personas encargadas de la garantía de calidad adquieren un rol más inteligente e interesante.
      - Escribir el ejemplo (test) antes que el código nos obliga a escribir el mínimo de funcionalidad necesaria, evitando sobrediseñar.
      - Cuando revisamos un proyecto desarrollado mediante TDD, nos damos cuenta de que los tests son la mejor documentación técnica que podemos consultar a la hora de entender qué misión cumple cada pieza del puzzle.
- - - - Experto
        
        El experto en diseño orientado a objetos buscará un test que fuerce al SUT a tener una estructura o una API que sabe que le dará buenos resultados en términos de legibilidad y reusabilidad.
        
        Un experto es capaz de anticipar futuros casos de uso y futuros problemas y será más cuidadoso diseñando la API test tras test, aplicando las buenas prácticas que conoce.
      - Junior
        
        El junior probablemente se siente a escribir lo que mejor le parece, sin saber que la solución que elige quizás le traiga quebraderos de cabeza más adelante.
        
        La ventaja es que, cuando se dé cuenta de que su diseño tiene puntos a mejorar y empiece a refactorizar, contará con un importantísimo respaldo detrás en forma de batería de tests. Por poco experimentado que sea, se cuidará de no diseñar una API que le resulte casi imposible de usar.
  - - - spikes
        
        Si el spike es pequeño, y resulta que nos damos cuenta que su propio código es válido tal cual, entonces escribiremos el test justo a continuación, en lugar de dejarlo sin test. Sin un conocimiento básico de la API y las restricciones del sistema, no recomendaría lanzarse a escribir especificaciones.
        
        es un pequeño programa que se escribe para indagar en la herramienta, explorando su funcionalidad. Es hacerse alguna función o alguna aplicación pequeña que nos aporte el conocimiento que no tenemos.
  - - - ¿Cuales?
        
        La siguiente recomendación es que la nueva API y la vieja convivan durante un tiempo, en lugar de reescribir eliminando la versión legada. Además de tener dos API podemos sobrecargar métodos para intentar que el código legado y su nueva versión convivan
        
        Otra alternativa para hacer TDD con código nuevo que colabora con código legado es abusar de los objetos mock.
        
        Digamos que los tests van a ser más frágiles de lo que deberían pero es mejor usar paracaídas que saltar sin nada.
        
        si el nuevo código es más independiente, podemos seguir haciendo TDD sin ningún problema. Se lo recomiendo encarecidamente.
        
        Si es una web, por ejemplo, agarrar Selenium o similar y grabar todos los posibles usos de la interfaz gráfica para poderlos reproducir después de las modificaciones y comprobar que todo el sistema se sigue comportando de la misma manera.
        
        Mi recomendación, antes de ponerse a reescribir partes de código legado, es crear tests de sistema (y cuando el código lo permita, tests unitarios) que minimicen los posibles efectos colaterales de la reescritura.
        
        El libro más recomendado por todos en los últimos tiempos sobre este asunto es, Working Effectively with Legacy Code de Michael C. Feathers. Tratar con código legado no es moco de pavo. En general, por código legado entendemos que se trata de aquel que no tiene tests de ningún tipo.
        
        Para los nuevos requisitos de la aplicación, es decir, aquello que todavía falta por implementar, podremos aplicar eso de escribir el test primero y luego el código (¡y después refactorizar!). Es probable que el nuevo SUT colabore con partes legadas que no permiten la inyección de dependencias y que no cumplen una única responsabilidad; código legado que nos dificulta su reutilización.
- - - - Tenemos que hacer el esfuerzo de imaginar cómo seria el código del SUT si ya estuviera implementado y cómo comprobaríamos que, efectivamente, hace lo que le pedimos que haga.
      - La diferencia con los que dictan una JSR es que no diseñamos todas las especificaciones antes de implementar cada una, sino que vamos una a una siguiendo los tres pasos del algoritmo TDD.
    - - La palabra especificación podría tener la connotación de que es inamovible, algo preestablecido y fijo, pero no es así.
      - Un test se puede modificar. Para poder escribirlo, tenemos que pensar primero en cómo queremos que sea la API del SUT, es decir, tenemos que trazar antes de implementar. Pero sólo una parte pequeña, un comportamiento del SUT bien definido y sólo uno.
  - - - Si estamos bien concentrados, nos vendrán a la mente dudas sobre el comportamiento del SUT ante distintas entradas, es decir, los distintos flujos condicionales que pueden entrar en juego; el resto de especificaciones de este bloque de funcionalidad.
        
        Estaremos tentados de escribir el código que los gestiona sobre la marcha y, en ese momento, sólo la atención nos ayudará a contener el impulso y a anotar las preguntas que nos han surgido en un lugar al margen para convertirlas en especificaciones que retomaremos después, en iteraciones consecutivas.
      - En este paso, la máxima es no implementar nada más que lo estrictamente obligatorio para cumplir la especificación actual. Y no se trata de hacerlo sin pensar, sino concentrados para ser eficientes. Parece fácil pero, al principio, no lo es; veremos que siempre escribimos más código del que hace falta.
  - - - Siempre que llego al paso de refactorizar, y elimino la duplicidad, me planteo si el método en cuestión y su clase cumplen el Principio de una Única Responsabilidad y demás principios.
        
        se aplican unos determinados cambios que mejoran el diseño del software mientras que su comportamiento sigue siendo el mismo.
        
        Mejora es una palabra ciertamente subjetiva, por lo que empleamos la métrica del código duplicado como parámetro de calidad.
        
        Si no existe código duplicado, entonces hemos conseguido uno de más calidad que el que presentaba duplicidad.
      - El propio Fowler escribió uno de los libros más grandes de la literatura técnica moderna en el que se describen las refactorizaciones más comunes. Cada una de ellas es como una receta de cocina.