Aprende a TRIANGULAR en TDD para pasar de rojo a verde #TestDrivenDevelopment

Summary

Este video script aborda el concepto de TDD (Desarrollo guiado por pruebas) a través de un ejemplo práctico. Se inicia creando un test para calcular el precio de un producto con impuestos, seguido por la implementación del código necesario para pasar el test. El proceso se enfatiza en las fases de rojo, verde y refactorización, destacando la importancia de diseñar desde la perspectiva del cliente y minimizar el tiempo en la fase verde para evitar un diseño excesivamente complicado. Además, se mencionan diferentes estrategias para pasar a verde, como la implementación obvia y la triangulación, que fomentan una mejor comprensión y mejora del código.

Takeaways

• 📝 El desarrollo TDD (Desarrollo por Pruebas) comienza escribiendo un test antes del código.
• 🔍 Se analiza el flujo de desarrollo TDD en un ejemplo práctico.
• 📚 Se menciona el uso de repositorios como Kitsap para encontrar ejemplos y ejercicios de TDD.
• 📁 Se describe la estructura de las carpetas en el repositorio, incluyendo 'code' y 'exercises'.
• 🛠️ Se implementa un ejemplo sencillo para calcular el precio de un producto con impuestos.
• 🔴 En la fase 'roja', se escribe el test y se deja que falle intencionalmente para modelar el comportamiento deseado.
• 🟢 En la fase 'verde', se implementa el código para pasar el test, pero se busca hacerlo lo más simple posible.
• 🔄 Se abordan diferentes formas de pasar a verde, incluyendo 'obvious implementation'.
• 🔄 Se menciona la 'triangulación' como un método para mejorar el código, forzándolo a cambiar para cumplir con múltiples tests.
• 🔄 Se destaca la importancia de pasar rápidamente por la fase verde para evitar perderse en el diseño detallado.
• 🔍 Se sugiere que el TDD se aplica no solo a algoritmos, sino también a aplicaciones más complejas y al mundo real.

Q & A

¿Qué es TDD y cómo se relaciona con el desarrollo de software?

TDD (Test-Driven Development) es un enfoque en el desarrollo de software que prioriza la escritura de tests antes del código fuente. Se relaciona con el desarrollo de software al proporcionar un enfoque iterativo y incremental que mejora la calidad del código y facilita la implementación de nuevas funcionalidades.

¿Cuál es el primer paso en TDD según el script?

El primer paso en TDD es escribir un test que falle, es decir, un test que especifica un comportamiento que el código aún no implementa.

¿Qué se hace en la fase 'roja' de TDD?

En la fase 'roja', se escribe un test que falla y se asegura de que el código fuente no cumpla con el comportamiento esperado, lo que hace que el test falle como se espera.

¿Qué se busca lograr en la fase 'verde' de TDD?

En la fase 'verde', se implementa el código necesario para hacer pasar el test que fallaba anteriormente, es decir, se busca que el código fuente cumpla con el comportamiento especificado en el test.

¿Qué es la fase 'refactor' en TDD?

La fase 'refactor' es cuando se mejora y se limpia el código fuente para que sea más eficiente y mantenible sin alterar el comportamiento que ya se ha probado con los tests.

¿Qué es el repositorio de Kitsap y cómo se relaciona con TDD?

El repositorio de Kitsap es un conjunto de ejemplos de código y ejercicios que se utilizan para enseñar y practicar TDD. Se relaciona con TDD porque proporciona un entorno donde se pueden aplicar los conceptos de TDD a través de diferentes ejercicios y situaciones.

¿Qué es un 'mock' y cómo se utiliza en TDD?

Un 'mock' es un objeto que simula el comportamiento de un objeto real para poder probar el código que interactúa con él. En TDD, se utilizan mocks para aislar las partes del código que se están probando y así poder verificar su comportamiento de manera controlada.

¿Qué es la 'triangulación' en el contexto de TDD?

La 'triangulación' es una técnica en TDD que consiste en tener varios tests que cubren diferentes aspectos de la funcionalidad del código. Esto ayuda a forzar cambios en el código para que todos los tests se cumplan, asegurando así una mejor cobertura y calidad del código.

¿Qué es el 'principio de segregación de interfaces' y cómo se aplica en TDD?

El 'principio de segregación de interfaces' es un principio SOLID que sugiere que las interfaces deben ser lo suficientemente pequeñas para que solo los clientes que interactúan con ellas las usen. En TDD, esto se aplica al diseñar las interfaces de los métodos basándose en lo que los clientes necesitan, no en lo que la implementación ofrece.

¿Cómo se puede aplicar TDD en aplicaciones más complejas, como sistemas de suscripciones?

En aplicaciones más complejas, TDD se puede aplicar siguiendo el mismo ciclo de escribir tests, implementar código y refactorar. Se pueden crear tests que cubran diferentes escenarios y comportamientos del sistema, como la gestión de licencias o la interacción con otros módulos, asegurando así que el código sea robusto y que cumpla con las especificaciones.

Outlines

00:00

🔍 Introducción a TDD y ejemplo práctico

El primer párrafo introduce los conceptos básicos de TDD (Desarrollo por Pruebas), destacando la importancia de escribir primero los tests y luego el código. Se menciona la práctica de TDD en la realidad, con ejemplos de código y la utilización de repositorios como kitsap para ilustrar el proceso. Se habla de la estructura de carpetas en el repositorio, donde se encuentran ejercicios y ejemplos para cursos, y se propone un ejemplo sencillo de calcular el precio de un producto con impuestos para aplicar TDD.

05:01

📝 Proceso TDD y creación del primer test

Este párrafo describe el proceso de TDD, enfocándose en la creación del primer test. Se explica cómo se modela el contrato del método total basado en las expectativas del cliente. Se menciona la importancia de definir interfaces desde la perspectiva del cliente y se discuten las decisiones tomadas en el diseño inicial, como la definición del constructor de la clase producto. Además, se aborda la fase roja del TDD, donde se intenta que el test falle intencionalmente para luego pasar a la fase verde, donde se implementa una solución básica que pasa el test.

10:03

🚀 Continuación del TDD y planteamiento de futuras mejoras

El tercer párrafo sigue con el proceso de TDD, destacando la importancia de pasar rápidamente por la fase verde para evitar perder tiempo en diseño innecesario. Se menciona la implementación obvia y se sugiere que hay diferentes formas de pasar a verde. Se habla de la triangulación en TDD, que implica forzar cambios en el código de producción para cumplir con los requisitos mínimos. Se anticipa que en futuros videos se mostrarán ejemplos más complejos de TDD en aplicaciones reales y se invita a los espectadores a suscribirse y seguir el curso para más información.

Keywords

💡TDD (Test-Driven Development)

El Desarrollo Guiado por Pruebas (TDD) es un enfoque de programación donde se escriben pruebas antes de escribir el código que debe pasar esas pruebas. Este concepto es central en el video, ya que se discute cómo aplicar TDD en la práctica al implementar un ejemplo concreto. El proceso se describe en tres fases: rojo (escribir una prueba que falla), verde (hacer que la prueba pase) y refactorizar (mejorar el código manteniendo su funcionalidad).

💡Repositorio

Un repositorio en el contexto de desarrollo de software es una ubicación centralizada donde se almacena y gestiona el código fuente. En el video, se menciona un repositorio de 'Katas de código' utilizado para mostrar ejemplos y ejercicios, demostrando la práctica de TDD.

💡Fase Roja

La 'fase roja' es el primer paso en el ciclo de TDD donde se escribe una prueba que falla. Esto verifica que el requisito o funcionalidad a implementar aún no existe en el código. En el video, se describe cómo se crea un test que espera cierto comportamiento del código (como calcular el precio de un producto con IVA), el cual inicialmente falla porque la funcionalidad no está implementada.

💡Fase Verde

La 'fase verde' sigue a la fase roja en el ciclo de TDD. Consiste en escribir el mínimo código necesario para que la prueba escrita previamente pase. En el video, esto se ilustra al implementar la funcionalidad requerida para calcular el precio de un producto con impuestos, logrando que la prueba pase.

💡Refactorización

La refactorización es el proceso de modificar el código para mejorar su estructura y legibilidad sin cambiar su comportamiento externo. En TDD, esta etapa sigue después de que las pruebas pasan (fase verde) para optimizar el código y mantener su calidad. El video menciona la refactorización como un paso clave después de lograr que una prueba pase.

💡Prueba

Una prueba en el contexto de TDD es un conjunto de afirmaciones que verifica que una pieza de código funciona como se espera. En el video, se menciona la creación de pruebas para validar el comportamiento de un método que calcula el precio total de un producto, incluyendo los impuestos.

💡Implementación

En el contexto del video, implementación se refiere al proceso de escribir el código fuente que realiza las funciones deseadas. Se discute cómo, siguiendo TDD, la implementación se realiza después de escribir las pruebas, garantizando así que el código cumple con los requisitos especificados.

💡IVA

El IVA (Impuesto al Valor Añadido) es un tema específico del ejemplo utilizado en el video. Se trata de un impuesto aplicado sobre el precio de los productos, y el video muestra cómo implementar el cálculo del IVA en un producto mediante TDD.

💡Expect

En el contexto de las pruebas, 'expect' es una afirmación que se utiliza para definir el resultado esperado de una prueba. En el video, se utiliza 'expect' para especificar el valor esperado que debe devolver el método al calcular el precio total de un producto, incluyendo el IVA.

💡Clase Producto

La 'clase Producto' se utiliza en el video como ejemplo para aplicar TDD. Se menciona la creación de esta clase y cómo se le añade un método para calcular el precio total, demostrando cómo TDD guía el desarrollo de nuevas funcionalidades en una clase.

Highlights

Clarificación de conceptos de TDD (Test-Driven Development).

Proceso de desarrollo TDD: escribir el test primero, luego el código.

Ejemplos de código y prácticas de TDD de Giordani.

Implementación de un ejemplo con TDD: calcular el precio de un producto con impuestos.

Uso del repositorio de kitsap, code y tv para ejemplos y cursos.

Categorización de códigos y enlaces simbólicos en el repositorio.

Ejercicios de TDD en la carpeta 'exercise'.

Creación del repositorio y clonación para el ejercicio de productos.

Uso de TDD para modelar el contrato de un método y la clase de un producto.

Fase roja de TDD: creación del test y expect.

Fase verde de TDD: implementación del código para pasar el test.

Fase de refactorización: mejora del código manteniendo el comportamiento esperado.

Triangulación en TDD: forzar cambios en el código para cumplir con múltiples tests.

Estrategias para pasar a verde de manera eficiente y rápida.

Importancia de mantener un enfoque de diseño mínimo en la fase verde.

Ejemplo de cómo el test influye en la implementación del constructor de la clase producto.

Discusión sobre la implementación obvia y cómo evitar ciclos de implementación innecesarios.

Planificación de futuras sesiones de TDD con ejemplos más complejos y aplicaciones del mundo real.

Transcripts

ya tenemos mínimamente claro los

conceptos de td de ese flujo de

desarrollo que primero escribe el test

luego el empleo vale vale vale pero en

la práctica esto qué tal vamos a ver

ejemplos de código giordani por donde

empezamos cuéntanos que vamos a

implementar un ejemplo con td y para eso

tenéis aquí el repositorio de kitsap

code y tv barras de facto ni escotes

mails tenemos aquí varios ejemplos

varios ejercicios vale este es el

repositorio que hemos usado también para

los cursos por ejemplo de factoring si

os fijáis ahí la primera carpeta es code

es mails donde básicamente encontraremos

la categorización de los distintos

olores de nuestro código y dentro de

esto carpetas que tienen enlaces

simbólicos a lo que veíamos antes es

decir el code es mail the data clan pues

aquí nos encontraríamos el enlace

simbólico a los ejemplos que ponen de

evidencia este color en el código esta

mala praxis potencial total que hemos

usado esto y aquí tenemos la carpeta

exercise skin con distintos ejercicios

cuéntanos eso son ejercicios que podemos

implementarlos de diferentes formas

tienes darles diferentes soluciones y

nos vamos a basar en ellos a la hora de

hacer recurso

para este primer vídeo vamos a hacer un

ejemplo muy sencillo pero que nos vamos

a poder llevar todos los conceptos que

hablamos el vídeo anterior a la práctica

que es calcular el precio de un producto

teniendo en cuenta los impuestos valen

perfecto es decir yo tengo un producto

que vale 10 euros pero como estoy en

españa que el impuesto del valor añadido

el iva es del 21% eso es realmente de

canas a la venta de personas físicas

finales tienen que ser 12 con 10 vamos a

dale caña oye nos creamos el repositorio

si usáis un temple y lo que queráis

nosotros vamos a aclararlo y en realidad

lo tengo clonado ya así que me voy

directamente a la carpeta en este caso

el ejercicio de productos zinc me voy a

la base de taiz script y lo abrimos en

el en el interior vale intel y la idea

es el y de que estamos usando

básicamente nos ofrece algunas

herramientas de rafa terminal que

estamos acostumbrados y tiramos por ahí

comentarnos qué opináis vosotros y que

planning si utilizáis otros editores

tipo visual estudio pues utilizáis total

que ya tenemos esto nos ahorra el boiler

plate podemos ejecutar los test para ver

qué funciona al final el único test case

que ya nos da

la base es validar que pues esto se

puede ejecutar y pasa a la suite es ahí

lo vemos a la derecha del todo con los

tics en verde perfectos más cositas

vamos a empezar para la fase roja en

la fase el rojo y cuál es el primero

ahora empieza lo interesante cuál es el

primer test que te pide el cuerpo a

hacer vale que un

producto le voy a pasar un precio unos

productos tienen precio y quiero

llamarle a un método total que me

devuelva al total con él iba vale

perfecto démonos cuenta de que esto al

final lo interesante de estos vídeos es

ver cómo trabaja otra gente entonces

ahora dan y démonos cuenta que lo

primero que ha hecho ha sido crear ese

test ya le pondrá el nombre luego y

seguidamente lo primerísimo ha sido

poner el expect es decir el método que

hace la sesión va a hacer la validación

de que nuestro código se comporta como

queremos en concreto ha hecho la

validación de que habrá algo que se

llame producto que ya ahora está

definiendo pero lo importante es que

primero han hecho hoy ese producto a

tener un método total que me va a

devolver algo que va a ser 12.1 esto es

súper interesante porque es ahí donde

estamos modelando cuando decimos que

estamos diseñando en rojo lo que sea

ahora estábamos diseñando el contrato de

ese método total que no recibe nada pero

que devuelve un valor numérico y tal es

igual total también estamos diseñando

cuando hemos dicho en la línea 5 que el

constructor por defecto de la clase

producto tiene un argumento que es su

precio hemos tomado muchas decisiones

aunque parezcan sólo dos líneas

triviales y la gracia de esto es poder

pensar en extrapolar estos casos más

complejos que sí que requieren de

colaboradores de no no por qué la clase

produzca el q leito requiere de un

servicio que se tenga que ir a ver el

país en el que estamos no sé que no sé

cuánto pues desde el momento en que

primero hacemos la selección el expect

es como se despreocupó de eso ya veré el

modelado de colaborador digital yo sé

que quiero llegar a este punto lo bueno

de esto es que cuando hemos hecho el

espectro ponemos en la piel del cliente

no de quién va con quién va a usar esta

clase o quién va a usar esta

funcionalidad o este módulo entonces

estás diseñando desde ese punto de vista

que como me gustaría llamar a esto y ya

te pones un poco en ese embudo de post

sea desde fuera me gusta mucho esto

tiene que ver mucho también con

principios solid interface gration

principal no es segregan las interfaces

de hacerlas más pequeñas sino es definir

las interfaces contratos desde el punto

de vista de los clientes las interfaces

pertenecen a quienes las utilizan no a

las implementaciones primeras que haya

total seguimos tenemos el test y tenemos

al antes que falla porque va a fallar y

no sale por ahí le ha fallado porque el

producto no sé que el constructor no

existe card podríamos ir varias de

montes que falla para entonces pasamos a

la fase verde pues en realidad no porque

el terno está fallando por lo que

queremos que falle no sabemos que falló

porque ese total no devuelve a 12,1 by

una cosa danny en la clase productos y

que la hemos creado ahora sí que la

hemos importado y lo vemos en línea 1 y

por producción src productos y se nos

hay que tiene en la base lo hemos

añadido pero podríamos haber no haberlo

puesto es simplemente una clase vacía lo

hubiéramos tenido que crear en este

momento vale démonos cuenta de que el

hecho de hacerte de también nos ayuda a

agilizar el proceso de implementación

porque si ahora nos vamos al test a

producto punto ts vemos que el líder ya

no se está descargando como error es esa

llamada ese método total esa llamada ese

constructor con eso con ese argumento de

entrada y entonces nos está sugiriendo

que quieres crear el constructor que ya

reciba un nombre ya lo he deducido yo

entonces yo pues si number le podríamos

poner un poco de name in aquí de oye

pues esto ya sabemos que va a ser el

precio van si o lo que sea de momento

tiramos así y tienes que dejar tener

nuestro tarta no menos este caso pues

delante vamos a intentar que esa fase

rojo es intentar que aunque no está

perfecto vamos a intentar rápido a que

esto falle por el motivo queremos que

falle que queremos que aquí ver un el

test está pasando vale vale porque

estamos tirando

tenemos que tirar estar discreto no

estaba teniendo en cuenta en este

momento esto vamos a tirarlo y ahora sí

que antes a un error de compilación

estábamos quedando el test de celo word

digamos lo que sufrimos funciona ahora

si vemos el test de que falla por el

motivo que queremos vale es decir vemos

oye se esperaba 12.1 importante aquí el

orden de los argumentos según la suite

de la librería de testing que usemos

están atentos a que le estamos pasando

el argumento esperado en el orden que

toque o lo que sea y se ha recibido ante

find con lo cual ahora sí que tenemos el

ts en rojo no nos interesaba pasamos a

la fase verde pasamos a la zona verde

lakers vamos a ir en tres fases verdes

tenemos que intentar que dure lo menos

posible en general vale porque si no nos

vamos a perder metiendo mucho diseño es

un ejemplo muy sencillo vale veremos

luego como diferentes formas de

implementarlo de llegar a la solución

final por ende es la forma perdona esto

es súper interesante lo han dicho muy de

pasada es súper interesante hay

distintas formas de pasar a verde las

veremos en el curso todas de forma

pausada y demás ahora por cual vamos a

optar vamos a ir directamente ir a

aceitar el resultado es que va a hacer

que este método total devuelva lo que le

hemos dicho que tiene que tiene que

volver en este caso 12,1 así que vamos

al método y le decimos oye molaría poner

el tipo de retorno en total vamos a

esperamos a otra facto

esto esto es algo que me produce

frustración de dt de que es ostia pero

sí ya sé que esto va a acabar siendo

number x

21% y ya sé que el total va a grabar un

number como elegir ser más puristas del

td va a venir hoy si estás tocado por mi

varita en este caso lo podríamos haber y

queremos que esto el vuelo number o lo

que sea o que el constructor le vamos a

llamar para ello por ejemplo you need

price pero estamos intentando

ejemplificar por qué cuando el problema

es más complejo en realidad no vas a

apoderar de estarte en verde tomando

todas y cada una de las 16 de diseño te

vas a perder entonces sí que es mejor

reducir el tiempo que estamos en verde

en la fase verde vale perfecto y además

cuando hablábamos de que hay distintas

formas de pasar a verde también hay una

de ellas que se conoce como obvios

implementation esto que nos habla así a

grandes rasgos o yo simplemente sería

que si llegase que aquí el proyecto que

pasa el constructor el price y en total

voy a multiplicar el transporte del diva

que ya todos lo estáis viendo pues

directamente

hace un test que el valide un caso y

implementarlo no empieces a hacer ciclos

que te torturen hay mucho tiempo veremos

dónde tiene más sentido tirar de un lado

que de otro en cualquier caso volviendo

al ejemplo tenemos esto ya pasando en

verde tenemos en verde así que ahora ya

no estaríamos en verde habría cabo la

fase estaríamos en fase de reactor sería

un buen momento por tanto para guardar

partida de hacer ese cómic que decíamos

y poder empezar a trastear con el código

qué cosa te pide el cuerpo aquí pues lo

que tú me has dicho podríamos empezar a

decir oye que esto es un anverso de esto

no me gusta que se llame number porque

ya sé definido desde el test que esto es

el precio y entonces podemos empezar a

hacer estas cositas vale vale a partir

de aquí existen diferentes formas ahora

de trabajar vamos a mencionar las pero

cómo podemos ir más metódicamente hemos

hablado de beers implementation hemos

hablado de fake it y también tenemos la

triangulación vale que sería como forzar

a que nuestro código cambie con que

triangular que hicimos en esto con otro

test vale es decir tenemos un primer

elemento que es el test que ya hemos

implementado tenemos un segundo elemento

que es la implementación del código que

da respuesta a ese test it

introduciremos un tercer elemento de ahí

lo de triangular que es el que nos

fuerza a jugar con esa implementación

para que cumpla tanto uno como otro y es

ahí donde se pone en valor lo que

estamos haciendo porque si no parecería

muy obvio parecería muy despreciable

vamos a decir esto de ir súper estrictos

y tal y es justamente cuando empezamos a

triana cuando empezamos a buscarle las

cosquillas al código de producción y

hacemos que cumpla con los requisitos

mínimos indispensables que realmente nos

han pedido y demás vale pues ahora

habríamos empezamos segundo el ciclo de

td en el que para 20 tiene que ser 24 2

y nuestro código de producción no está

cumpliendo con esto perfecto entonces

ahora tenemos tres formas de podemos

seguir trabajando en esto hasta llegar a

la solución que es que hagamos alguna de

ellas sólo lo vemos en los siguientes

vídeos logramos en los siguientes vídeos

ya sabéis suscribiros like y curso en

pro punto conjunto de v donde vamos a

ver estos ejemplos y muchos más e

interaccionando con oye qué pasa cuando

tenemos un sistema de suscripciones como

el eco del y que en función de la

empresa número de licencias que tenga

cae en un sitio u otro y ese sistema

interacciona con strike entonces vamos a

modelar aplicaciones del mundo real con

td que es donde se pone más claro dónde

está esa línea de lo que es obvio y lo

que no depende de la persona no lo

veremos entonces

como llevo todo esto de triangular de

triangular desde el apio tiramos un

alimento es que ahora estamos tirando

por el típico ejemplo que siempre se

pone de td que es modelar algo

algorítmico por así decirlo pero en

aplicaciones de app y http o cosas más

completas vamos a decir estaría bien que

empezaremos a testear desde el punto en

el que hemos empezado que es la entidad

producto pues vamos a

cuestionarnos ese tipo de cosas y vamos

a llevarlas al mundo real más allá de

catas y ejercicios básicos con lo cual

nos esperamos y en el siguiente vídeo va

por ello vamos a ver cómo tras acabar

con este código hasta ahora