Revisión 1: ¿Qué Hemos Aprendido Hasta Ahora Sobre TDD?

¿Cuál es la mayor diferencia entre TDD y las pruebas unitarias (unit testing)?

• Nada, son lo mismo.

• Obtienes una mayor cobertura de pruebas con TDD.

• Las pruebas unitarias nos permiten ahorrar tiempo al dejar las pruebas para después de que el código esté terminado. Por lo tanto, podemos omitirlas si nos quedamos sin tiempo.

• 
  En TDD diseñamos nuestro código a partir de pruebas, escribiendo primero la prueba y después el código.

Answer explanation

El Desarrollo Dirigido por Pruebas (TDD) se trata específicamente de conducir el proceso de desarrollo a partir de pruebas. Comenzamos escribiendo una prueba primero y luego creamos el código necesario para que la prueba pase. Esto tiene muchos beneficios.

Los equipos que practican TDD tienden a tener una cobertura de pruebas muy alta, pero ese no es su objetivo. Los equipos que escriben pruebas unitarias después de escribir el código también pueden lograr niveles elevados de cobertura, pero esto a menudo conlleva un alto acoplamiento entre las pruebas y el código.

La terminología en torno a TDD y las pruebas unitarias puede resultar confusa. TDD produce pruebas unitarias. "Pruebas Unitarias" puede referirse a pruebas de enfoque estrecho, con las pruebas escritas antes o después del código, pero TDD siempre significa que las pruebas se escriben primero. Por lo tanto, para simplificar, en este curso describimos TDD como SIEMPRE escribir las pruebas primero, y las Pruebas Unitarias como escribir las pruebas después.

Las pruebas deben ser "comprensibles". ¿Cómo ayuda TDD a mejorar la "comprensibilidad" de nuestras pruebas?

• Las pruebas de TDD son más cortas, por lo que hay menos que leer y entender.

• Escribir la prueba antes del código te obliga a pensar en lo que realmente estás tratando de lograr. Entences la prueba expresa ese deseo de comportamiento.

• Cuando las pruebas se escriben antes del código, están dirigidas por una implementación específica que tienes en mente, por lo que tienden a ser menos abstractas. Como resultado, a menudo son más fáciles de entender.

Answer explanation

Escribir la prueba primero significa que no tenemos una solución en mente, a menos que estemos haciendo trampa. Esto significa que hay una mejor oportunidad de que nuestras pruebas se centren en los resultados que queremos de nuestro código, en lugar de en los detalles de la implementación.

Esto significa que nuestras pruebas están menos ligadas a detalles de implementación específicos y funcionan como una declaración más precisa de lo que nuestro código debe hacer en lugar de cómo lo hace. Esto las hace mucho más fáciles de entender.

Centrarse en el comportamiento deseado del código nos lleva a pensar más desde la perspectiva de un usuario de nuestro componente, clase o método. Nos lleva a diseñar desde afuera hacia adentro, en lugar de desde adentro hacia afuera. Esto significa que la prueba tiende a ser una descripción más clara del resultado deseado.

¿Por qué es importante la modularidad para un código de alta calidad?

• Nos permite mantener partes del sistema en archivos y repositorios separados, lo que nos permite trabajar en ellos de forma independiente de otros módulos.

• Nos permite descomponer problemas en piezas más pequeñas, cada una más enfocada, más independiente y más componible. A menudo, la modularidad también ayuda a que nuestros sistemas sean más escalables.

• Los sistemas modulares aseguran que los desarrolladores puedan comprender cuando algo cambia en otras partes del código.

• Los sistemas modulares son más rápidos, más fáciles de deployear y simplifican la escritura de pruebas para ellos.

Answer explanation

La modularidad es una de las cinco propiedades del código de alta calidad: Modularidad, Cohesión, Separación de Responsabilidades (concerns), Abstracción y Acoplamiento Ligero.

Juntas, estas propiedades en el código nos permiten gestionar su complejidad, facilitándonos mantener la capacidad de cambiar el código de manera segura siempre que sea necesario y donde sea necesario.

La modularidad ayuda al descomponer problemas en piezas más pequeñas y comprensibles. Cada pieza se enfoca en resolver una parte particular del problema, lo que a menudo significa que los módulos pueden ser utilizados en otros contextos también. Podemos componer nuevos sistemas y comportamientos a partir de módulos existentes.

Los sistemas modulares también nos permiten construir sistemas que pueden manejar cargas más altas, ejecutando muchas copias de un módulo en paralelo con otros.

¿Qué significa el "Rojo" en "Rojo, Verde, Refactor"?

• No escribas pruebas hasta que sepas todo lo que necesitarás probar.

• No escribas pruebas hasta que el equipo de control de calidad (QA) te indique qué probar.

• Tu prueba está rota, busca ayuda.

• Tu prueba está fallando, como esperabas. Estás listo para hacer que pase.

Answer explanation

Nuestro objetivo en el paso "Rojo" es centrarnos en el diseño de nuestro sistema desde el exterior. Utilizaremos la creación de una prueba para ayudarnos a adoptar este enfoque "de afuera hacia adentro".

Crearemos una prueba que exprese algún comportamiento nuevo de nuestro sistema. Escribiremos solo la cantidad suficiente de código para que la prueba y el código se compilen, se ejecuten y fallen.

Predicaremos cómo esperamos que la prueba falle y luego la ejecutaremos y confirmaremos que falla de la manera en que esperábamos, para asegurarnos de que la prueba funciona correctamente y está afirmando las cosas correctas.

¿En qué debes enfocarte al COMIENZO del paso "Verde" en "Rojo, Verde, Refactor"?

• Tu prueba está pasando, así que ahora enfócate en un gran diseño para tu implementación.

• Tu prueba está pasando, así que ahora enfócate en romperla para que puedas probar tu prueba.

• Tu prueba está fallando en este momento, así que ahora encuentra la ruta más corta y simple para hacer que pase.

• Tu prueba está fallando, así que refactoriza la prueba hasta que pase.

• Tan pronto como tu prueba pase, puedes pasar a la siguiente prueba.

Answer explanation

Al entrar en el paso "Verde", nuestra prueba está fallando de la manera que habíamos predicho, por lo que sabemos que está probando las cosas correctas.

Ahora nuestro código está en un estado inestable, si hacemos demasiado trabajo en este punto, corremos el riesgo de agravar problemas y no verlos claramente, porque los nuevos problemas pueden estar ocultos por el fallo de la prueba.

Nuestro objetivo entonces es volver a la estabilidad lo más rápido y sencillamente posible.

Este no es el momento adecuado para preocuparse por la solución perfecta, déjalo para el siguiente paso. En su lugar, encuentra la ruta más corta para que la prueba pase.

¿Cuándo debes "Refactorizar" en TDD?

• Refactoriza en "Verde" cuando tus pruebas estén pasando.

• Cuando tu código está roto.

• Todo el tiempo.

• Cuando tu supervisor lo programe.

• Refactoriza cuando aprendas algo nuevo.

Answer explanation

Si respondiste "Todo el tiempo" o "Cuando aprendas algo nuevo", toma algunos puntos de reconocimiento. Son respuestas válidas en general.

En TDD, sin embargo, tenemos un paso específico para la refactorización. Refactorizas solo cuando tus pruebas estén pasando.

Discutiremos la refactorización con más detalle más adelante en el curso, es una herramienta valiosa.

Recomendamos enfáticamente que mientras aprendes y practicas TDD, te obligues a la disciplina de hacer una pausa y pensar en lo que podrías cambiar cada vez que obtengas una prueba que pasa. Incluso si decides, en esta ocasión, que no hay refactorización que hacer.

Escribes una prueba, la ejecutas y ves que falla. Luego, mientras empiezas a pensar en cómo hacer que pase, te das cuenta de que sería mejor reestructurar el código primero. ¿Qué debes hacer?

• 
  Debes reestructurar el código cuidadosamente y ejecutar todas las pruebas al final para asegurarte de que tu prueba aún falle como esperas.

• Debes reestructurar el código cuidadosamente y ejecutar las pruebas regularmente para asegurarte de que no rompas ninguna otra prueba.

• Añade la nueva funcionalidad para que la prueba pase y luego refactoriza el código.

• Deshabilita la prueba que falla, ejecuta todas las demás pruebas para confirmar que pasan y luego refactoriza el código para prepararlo para la nueva funcionalidad.

Answer explanation

¡Siempre refactoriza en VERDE! Si intentas reestructurar el código mientras tienes una prueba que falla, es fácil enredarse. Puedes romper el código y los errores se verán ocultos por la prueba que falla.

En su lugar, comenta o deshabilita temporalmente tu nueva prueba que falla.

Vuelve a ejecutar todas las demás pruebas para confirmar que siguen pasando.

Ahora refactoriza el código en la nueva estructura que tienes en mente, ejecutando continuamente las pruebas para comprobar que no has roto nada.

Una vez que el código tenga la forma que deseas, vuelve a habilitar la prueba, ejecútala para ver que vuelva a fallar y luego comienza a implementar la nueva funcionalidad.

¿Por qué es el TDD una práctica esencial para la ingeniería de software de calidad?

(pista: estás buscando 3 respuestas correctas)

• Escribir pruebas significa que tienes la oportunidad de escribir más código.

• Te obliga a pensar en el problema antes de empezar a escribir el código.

• Amplifica las propiedades de un diseño de alta calidad en el código.

• Organiza el trabajo en torno a una disciplina simple centrada en el aprendizaje.

• Ahorramos tiempo al escribir menos pruebas.

Answer explanation

Si aspiramos a realizar un trabajo de mayor calidad, debemos encontrar formas de eliminar errores comunes y potenciar lo positivo en nuestro código, nuestro diseño y nuestra metodología.

El TDD ayuda con todos estos aspectos. Al enfocarnos en comenzar con una prueba, nos hace pensar primero en el problema que estamos resolviendo para definir un resultado de nuestro código que podemos probar.

Si terminamos escribiendo más código, en el contexto específico de ejemplos simples, en general escribiremos menos, porque el diseño de nuestro código será más flexible, más abstracto y, por lo tanto, más genérico.

Forzarnos a adoptar la disciplina de siempre comenzar con una prueba que falle tiene muchos efectos secundarios positivos. Amplifica las características que elegimos definir como "alta calidad" en el código. Nos hace diseñar el código desde el exterior, tomando la perspectiva de alguien que usa el código, en lugar de solo nuestra perspectiva como productores de código, lo que a su vez nos anima a crear código que sea más agradable de usar.

Finalmente, también facilita la creación de pruebas que no están fuertemente acopladas a ninguna solución particular, lo que significa que es menos probable que se rompan cuando necesitemos cambiar nuestro código.

La Entrega Continua aplica ideas de la ciencia al desarrollo de software de la siguiente manera:

(pista: solo una de estas es incorrecta)

• 
  Usar pruebas para demostrar que el nuevo código está libre de errores.

• 
  Recopilar retroalimentación rápida y de alta calidad de los clientes y pruebas automatizadas.

• 
  Aplicar el método científico para ser experimental y como ejercicio de aprendizaje.

• Utilizar medidas adecuadas para tomar decisiones basadas en evidencia.

Answer explanation

La aplicación del método científico en el desarrollo de software implica ser experimental y utilizar pruebas como un mecanismo de falsificación.

Un resultado de prueba positivo no necesariamente significa que el nuevo código sea bueno, pero una prueba fallida significa que hemos aprendido algo y podemos mejorar nuestro código.

En la Entrega Continua, nuestros "experimentos" consisten en utilizar pruebas automatizadas y mediciones adecuadas de retroalimentación para mejorar continuamente nuestro código.

Selecciona 3 buenos consejos para aprender TDD de la siguiente lista:

• Avanza en pasos muy pequeños.

• Asegúrate de saber cómo resolver todo el problema antes de escribir una prueba.

• No agregues código nuevo a menos que tengas una prueba que falle y te obligue a hacerlo.

• Siempre predice el resultado de tu prueba, incluso dilo en voz alta, antes de ejecutarla.

• Siempre escribe todas las pruebas antes de comenzar a escribir código, eso es verdadero "test-first".

Answer explanation

Trabajar en pequeños pasos es un aspecto importante de TDD, asegura que estemos siempre cerca del éxito y limita el impacto de cualquier error que cometamos.

Parte de esto implica descomponer la solución de problemas en pasos pequeños también. No intentes resolver el problema por completo, aprende a sentirte cómodo avanzando de manera más incremental.

Realiza cambios cuando sea seguro hacerlo, agrega nuevo código cuando tengas una prueba que falle y te guíe, y refactoriza cuando todas las pruebas estén pasando para que te guíen y te mantengan en el camino de manera segura.

No esperes conocer todas las pruebas que necesitarás antes de comenzar a trabajar. Una parte importante del beneficio de TDD es que nos ayuda a aprender. Escribe una prueba, haz que pase, mejórala y pasa a la siguiente prueba.

Predecir el resultado antes de ejecutar la prueba nos entrena a pensar más en términos de que cada prueba sea un pequeño experimento en el código; ¡este enfoque es muy saludable!