Vamos hoy a aprender desde cero TDD, vamos a hacer una pequeña, pequeña pincelada de...
de un poquito de explicación, qué es TDD, cómo funciona el TDD
y vamos a estar casi una hora y media programando, ¿vale?
Y vamos a estar programando justamente haciendo Test Driven Development
Así que vamos a arrancar con ello, ¿vale?
Venga, aquí tenemos... me he pillado estos slides que no sé de quién es
es de Ganesh Samarciam, así que muchas gracias por las slides
pero me he imaginado que tendría alguna imagen interesante y ya está
¿Cómo desarrollamos normalmente nuestro código?
Pues lo que hacemos es primero diseñarlo, luego lo codificamos, lo programamos
y luego hay gente que ya está, lo lleva a producción y luego se quema la casa
y ay, ay, ay, cómo ha podido pasar esto
y luego hay otra gente que le añade Test
y una vez que hace Test, lo que volvemos es a diseñarlo, codificarlo y testearlo
ya te digo que el paso de testear no es que lo haga todo el mundo
así que puede ser que tú lo estés testeando o ni siquiera lo estés testeando
porque, bueno, crees que ya te va bien no testearlo y ya lo tienes
Bueno, este sería la forma más antigua de programar normalmente
pero hoy vamos a ver una cosita un poco diferente
vamos a estar con el diseño, pero luego justamente después ya vamos a hacer el testing
o sea, vamos a escribir el test antes que el código
¿Pero esto qué es? ¡Estamos locos!
Bueno, vas a ver que tiene mucho más sentido de lo que parece
aunque al principio, en las primeras iteraciones puede parecer como
¡Ay, Midu, qué tontería!
Y bueno, conforme vas ganando más experiencia igual te puedes intentar saltar algún paso
pero vamos a ver que esto es literalmente así
primero escribes el test y luego el código
no haces ni una línea de código
ni una línea de código hasta que no tienes un test
lo vais a ver, que es muy bestia
pero lo vais a ver y es bastante interesante
Entonces, ¿qué es TDD?
A ver, mucha gente se cree que el TDD tiene mucho que ver con el test
y bueno, sí, tiene que ver con el test
pero en realidad no es una técnica para hacer test
es una técnica para desarrollar software
¿Vale?
es desarrollo guiado por pruebas
de hecho, ya lo dice aquí
TDD de Loveman es desarrollo guiado por test
por pruebas
Súper importante
porque normalmente
mucha gente se cree que a lo mejor el TDD es para hacer testing
y no es para hacer testing
es para codificar justamente
¿Vale?
Entonces, lo interesante de esto
es que vamos a utilizar los tests
que nos va a ayudar a crear el código que necesitamos
Entonces, mucha gente confunde
no sé lo que pone aquí, la verdad, no me lo he leído
pero mucha gente confunde lo que sería el testing
con QA
y no tiene nada que ver
¿Vale?
Tiene que ver con que hay tests por medio
están relacionados pero no son lo mismo
El TDD, lo que estaríamos haciendo son tests
antes de codificar
y el QA vendría mucho más tarde
¿Por qué?
Porque el QA lo que estaría es asegurándose
que el código funciona
por lo tanto estaría ya en una fase posterior
de la codificación
¿Qué pasa?
Que si tú haces TDD
seguramente la fase de QA
va a ser mucho más sencilla
Quality Assurance
es lo que significa QA
¿Vale?
Pero no significa
TDD no es QA
ni viceversa
Pero si haces TDD
la parte de QA
pues a lo mejor
es mucho más sencilla
¿Vale?
Ahora bien
¿Por qué se hace?
¿Por qué el TDD?
¿Por qué el TDD?
O sea
¿Por qué no usamos otra cosa?
Bueno
es que hacer los tests
justo después del código
en realidad
tiene algunas desventajas
la primera y la más importante
es que el test
no te está dando feedback
sobre tu código
y te voy a explicar por qué
porque puede ser
que tú hagas el código
y haces
imagínate
100 líneas
tú escribes un primer test
y ese test
¿de qué te está dando feedback exactamente?
¿De una parte del código?
¿De un corner case del código?
¿De algo?
¿Y qué pasa si haces el test
y de primeras te sale verde?
¿Sabes que realmente está funcionando?
¿Que no está funcionando?
¿Cómo te estás asegurando?
Eso es una desventaja
bastante clara
¿No?
Luego
el tema es que
una vez que tienes el código
puedes pensar que
hacer los tests
en realidad es una pérdida de tiempo
y digas
¡Bah!
Pues no voy a hacer los tests
porque no voy a invertir ese tiempo
el TDD
de alguna forma
te fuerza a hacer los tests
y de esta forma
esa inversión de tiempo
ya la tienes
y además luego te acelera
la codificación
porque te asegura
una base
en la que vas a estar
iterando totalmente
y luego
el problema que tienes
de crear los tests
después del código
es que normalmente
vas a intentar
testear el happy path
¿vale?
Siempre vas a estar
con el camino feliz
decir
como por ejemplo
voy a testear este caso
que es el que me interesa
pero nunca vas a estar
intentando decir
¡Ostras!
Voy a pensar en este otro caso
en este corner case
es más difícil
lo puedes hacer
pero obviamente
es más difícil
¿vale?
entonces
¿cómo sería el TDD?
un poquito
para que lo veamos así
vale
primero tendríamos
un rojo
haríamos un test
en rojo
una vez que tenemos
el test en rojo
lo que hacemos es
pasarlo a verde
o sea
hacemos un test en rojo
y luego hacemos
la implementación
en código
para que pase
a verde
y una vez que lo tenemos
en verde
podemos hacer
todos los refactos
que necesitemos
¿vale?
que necesitemos
imagínate
creamos un test
que una multiplicación
dos por dos
tiene que devolver cuatro
¿vale?
ahora creamos la implementación
se pasa cuatro
o sea
hacemos la implementación
para que devuelva cuatro
y luego pues decimos
vale
ahora que ya tengo un test
que justamente me asegura
que esto está funcionando
de esta manera
voy a estar refactorizando
el código constantemente
para mejorarlo
para cambiar el nombre
de las variables
y teniendo la seguridad
de que el test
me está protegiendo
mientras estoy
cambiando y mejorando
mi código
¿vale?
entonces
esto sería un poquito
el esquema
que tenemos que tener
que lo veremos luego
prácticamente
el red
el red es rojo
un pequeño test
que no funciona
¿vale?
tiene que empezar
que no funcione
si empezamos
y añadimos un test
que ya funciona
pueden estar pasando
diferentes cosas
una
que no hemos hecho bien
el test
o que estamos probando
ya un caso
que está cubierto
por otro test
y hay veces
y veremos esto
que el TDD
se pueden ir borrando
test anteriores
¿vale?
el verde
pues nada
esto significa
que el test funciona
perfecto
y el refacto
es eliminar duplicaciones
mejorar el código
hacer best practices
lo que sea
vais a ver una cosa
que es bastante importante
e interesante
del TDD
y es que el TDD
no significa
que tu código
vaya a ser el mejor
del mundo
de hecho
lo bueno que vas a hacer
es que primero
vas a hacer que funcione
y luego ya te vas a preocupar
de refactorizarlo
de hacerlo con mejores prácticas
pero lo bueno
es que lo vas a tener
con la base de test
y te va a ser mucho más fácil
de desarrollar
y hacer lo que quieras
las tres reglas
las tres leyes
del TDD
ley número uno
y estas son leyes
que tienes que tener
en la cabeza
ya veréis que estas leyes
conforme vas subiendo
un poco de nivel
vas a decir
bueno
me voy a saltar
este paso y tal
nosotros vamos a intentar
no saltarnos
absolutamente nada
¿vale?
ley número uno
no vas a escribir
no escribes código
de producción
a no ser
que hayas escrito
antes un test
que falle
no te vas a adelantar
nunca
de empezar a escribir
ahí
sin que lo necesites
no te vas a adelantar
a escribir código
si no has hecho un test
antes para comprobarlo
lo segundo
no vas a escribir
más de un test
más de los test
que sean necesarios
para que fallen
¿por qué?
porque tampoco se trata
de que escribáis
todos los test
y vais a ver un poco
luego lo vamos a ver
¿vale?
pero no se trata
de que escribáis
ocho test
que fallen de golpe
y esto es un error
que muchas veces veo
en TDD
que la gente dice
bueno
voy a escribir aquí
un montón de test
y se pone a escribir
test ahí
no se trata de eso
se trata de que tú
escribes un test
o sea
no tienes que escribir
más test de los necesarios
para que falle
o sea
si escribes un test
falla
pues ya está
ese test
lo que vas a hacer
es entonces
implementar el código
y vuelves otra vez
a los test
y así todo el rato
¿vale?
no es que haces 10
15 test
25 test
¿por qué?
porque eso también
te va a estar viciando
los test
y no quieres eso
de hecho te puedes estar
dando cuenta
de los corner cases
mientras los estás haciendo
¿vale?
así que nunca
nunca
hay que adelantarse
un test
normalmente es suficiente
y luego
tampoco vas a escribir
más código de producción
del que sea suficiente
para hacer que pase el test
¿por qué?
porque hay veces
que te puedes encontrar
y decir
ostras
ahora ya entiendo
la lógica
de este programa
hoy lo vamos a ver
con los programas
los ejercicios
que vamos a ver
vamos a hacer ejercicios prácticos
algunos
vamos a empezar sencillo
pero vas a ver
que poco a poco
lo vamos a complicar
y puede ser
que te veas
tentado o tentada
a decir
si yo esto ya lo domino
pues ya me adelanto
no
no te adelantes
tienes que escribir el test
nunca escriba más código de producción
del necesario
para que pasen los test
¿por qué?
porque si no
estás volviendo a viciar
la implementación final
se te pueden pasar
corner cases
o edge cases
o como lo quieras llamar
¿vale?
corner case
edge case
son casos
que no has tenido en cuenta
yo creo que se entendía
corner case
porque la gente está
pero eso no es un edge case
a ver
son lo mismo
corner está un corner
un edge
está un edge
o sea que es lo mismo
pero al final
son casos
que a lo mejor
son especiales
que no es lo común
y al no tenerlos en cuenta
se te pueden colar
y fallaría tu código
¿vale?
así que estas serían
las tres leyes del TDD
aquí
tenemos
mira
este sería el ciclo de desarrollo
lo vamos a ver ahora
y lo vamos a hacer ahora
y bueno
aquí tendríamos un poquito
el primer desarrollo
el escribir el test
que entonces falla
no sé qué
veis aquí tenemos
escribir un test
sería el primero
luego
el test falla
obviamente
y entonces tenemos
que escribir el código
suficiente para que funcione
y aquí ya sería
el refactor
¿por qué?
porque en el refactor
hay veces que te puede
fallar el test
una vez has hecho el refactor
pero lo bueno es que los tests
ya los tienes ahí
para que vayan funcionando
obviamente los beneficios
hay un montón de beneficios
hay un libro muy bueno
que habla de TDD
y de refactors
para el que no sepa
lo que son los refactors
un refactor
quiere decir
sobre reescribir
el mismo código
que ya hay
para que haga exactamente
lo mismo
pero con otra implementación
no debería cambiar
nada de la funcionalidad
pero el código
es más legible
tiene mejores prácticas
y todo esto
cuando tú utilizas TDD
puedes hacer tantos refactors
como quieres
como quieras
y de hecho hoy lo veremos
porque esta
es mucho más fiable
tú ya tienes los test
puedes estar escribiendo
el código
reescribiéndolo
tantas veces como quieras
sobre esa base
luego también tienes
otro beneficio
normalmente
terminas con un mejor diseño
esto lo vas a ver
muy claro
con el ejemplo
que vamos a hacer
de el algoritmo
un ejercicio
del App Engine
el más difícil
que a mucha gente
le costó
lo vas a ver clarísimo
lo vas a ver muy claro
¿por qué?
porque ese ejercicio
si lo hubieras hecho
sin TDD
dirías
lo hubiera hecho
de otra forma diferente
y mucho más difícil
así que normalmente
el TDD
te permite hacer
un mejor diseño
separando mejor
los casos
que tienes que tener
controlados
y todo esto
mejorar el code coverage
el code coverage
quiere decir
las partes del código
que tienes cubiertas
con test
depurar
mucho más rápido
obviamente
si haces un test
un solo test
te falla
y todos los demás
te van bien
y esto lo vas haciendo
constantemente
vas a encontrar
los errores
mucho más rápido
luego
vas a tener
documentación gratis
los test
aunque sé que a muchos
de ustedes
les da un poquito
de
bueno
como se dice esto
alergia
la gente le da alergia
a los test
y todo esto
pero lo cierto
es que los test
no solo te ayudan
a asegurarse
que tu código funciona
que es tu responsabilidad
por cierto
es tuya
es tuya
sino que también
te ayudan
a documentar el código
¿por qué?
porque en lugar de estar
poniendo comentarios
los test
yo lo he hecho muchas veces
he ido a un sitio
y en lugar de
entrar al código
he ido a los test
porque los test
al final son un montón
de casos de uso
para utilizar ese método
que te están documentando
las cosas que tienes que hacer
qué parámetros
le tienes que pasar
y qué es lo que deberías esperar
que te devuelva
así que es una forma
de documentar el código
súper interesante
súper limpia
y que además
obviamente tiene un beneficio
adicional
de asegurarte
que tu código
funciona
incrementan la calidad
por supuesto
código al final
mucho más limpio
gracias a los refactos
y bueno
que son casi todo
beneficios
hay un montón de herramientas
para hacer TDD
pero al final
vas a tener en cuenta
una cosa
casi cualquier framework
que conoces
para hacer testing
ya sea de javascript
no de javascript
lo que sea
vais a poder utilizar
ese framework
para hacer TDD
vamos a romper
una cosita
una lanza
y es
mucha gente cree
opina
y bueno
puede ser que lo piense
y ya está
que creen que hacer test
o TDD
hace que el desarrollo
vaya más lento
y la verdad
sinceramente
en mi opinión
es que
sí
y no
y te explico
qué pasa
al principio
cuando tú estás
empezando a desarrollar
obviamente puede ser
que vayas más lento
va más seguro
pero puede ser que vayas
un poquito más lento
pero
el desarrollo
nosotros pensamos
que el desarrollo
es de aquí
aquí
que es una línea recta
en la que va de A a B
y es obvio
que el TDD
cuando estás empezando
en el punto A
pues puede ser un poco más lento
que si lo hicieses de otra forma
pero
hay que tener en cuenta
que el desarrollo
nunca termina
por ejemplo
nosotros
seguimos trabajando en empresas
y ese código
va a quedarse ahí por siempre
así que
lo que
lo que te cuesta un poquito
al principio
de hacer TDD
es una inversión
a futuro
tanto para mantener
como para añadir
nuevas features
y eso te puede asegurar
que te lo acelera
muchísimo
muchísimo
y no tengo ningún tipo
de género de dudas
que lo hace
y yo al menos
siempre he agradecido
que ya tenga TES
y haciendo TDD
es súper simple
añadir una nueva feature
un nuevo caso
o sea
mucho más fácil
así que
ese peaje
que tocas al principio
es muchas veces
una inversión
que en el futuro
recoges
y que
si no tuvieses
si no hubieras utilizado
TDD
eso que al principio
va muy rápido
luego lo pagas
y normalmente
lo pagas muy caro
eso te lo puedo asegurar
¿vale?
tú ya casi no trabajas
en tu empresa
que grande
que grande
pero bueno
si que trabajo
hombre
si que trabajo
bueno
pues esto es súper tibio
que la gente dice
que vas más lento
y tal
vale
bueno
pues yo creo que
con esto
ya podemos
ya podemos
ya podemos darle
¿no?
vamos a iniciar
si os parece
yo voy a utilizar
VTEST
VTEST
es un framework
para hacer
TES unitarios
con el que vamos
a poder hacer
fácilmente
TDD
VTEST
podría ser
Jest
podría ser
Mocha
podría ser
lo que queráis
no es importante
el framework
que sí
lo importante
básicamente
es que hagáis
lo hagáis
con lo que queráis
¿y por qué no
Jest?
bueno
Daniel Suárez
¿y por qué no
Mocha?
oye
¿y por qué no?
¿y por qué no
Chai?
¿y por qué no?
¿y por qué no?
pues porque al final
da igual
¿sabes?
da igual que sea
VTEST
da igual que sea
Jest
me gusta VTEST
así que
vamos a hacer VTEST
sé que
podría ser
por qué no
y por qué no
de todo
pero aprende TDD
vamos a darle
aprende TDD
aprende TDD
vale
vamos a darle
al Get Started
y lo primero
que vamos a hacer
vamos a instalar
aquí VTEST
¿ok?
instalamos VTEST
es una dependencia
que utiliza VIT
es un framework
de testing
que es bastante nuevo
y es súper rápido
y lo vamos a ver
que la experiencia
de desarrollo
es tremenda
es tremenda
vale
voy a levantar
aquí
el proyecto
ya tengo esto
por aquí
voy a iniciar
también con
npm init
menos i
que esto lo que hace
es ya crearme
un package json
de hecho
ahora que veo
tendría que haber hecho
el npm install antes
¿no?
porque
¿ves?
no me ha dejado
la dependencia
vale
nos la dejamos
como dev dependency
voy a instalar
también
standard
standard es
como un conjunto
de reglas
del linter
que detecta
los errores
malas prácticas
que puedas tener
si hay fallos
estáticos
en tu código
y entonces
vamos a ver
vamos a tenerlo
porque también
es buena práctica
tenerlo
así que lo vamos a dejar
por aquí
slint config
extends
y vamos a poner esto
que esto extiende
de
node modules
standard
slint rc
json
ok
ahora que tenemos esto
necesitamos añadir
los scripts
para el testing
así que le vamos a dar aquí
y si no me equivoco
aquí tenemos estas dos
vamos a pegarlo
por aquí
y en scripts
quitamos este
y ya tenemos nuestro script
de vtest
y el de coverage
este de vtest
por defecto
lo que hace es un watch
va a estar mirando
constantemente los cambios
vale
así que ahora
vamos a crear una nueva carpeta
que le voy a llamar
test
vamos a hacer diferentes ejercicios
uno de ellos
el primero que quiero hacer
es el de fish bus
vale
voy a hacer el de fish bus
sé que es muy simple
pero esto nos va a permitir
justamente empezar
con algo fácil
luego una cata más difícil
luego una cata
bastante chunga
que es un ejercicio
y al final
vamos a hacer la aplicación
con react
una aplicación pequeña
pero para hacer
en el frontend
hacer tdd
vale
así que vamos a empezar
primero con fish bus
luego vamos en crechendo
vamos en crechendo
venga
que tenemos que hacer
bueno pues vamos a crear
nuestro test
porque lo primero
que tenemos que hacer
justamente es
crear nuestro test
así que hacemos
fish bus
punto test
punto js
voy a abrir la terminal
y la voy a poner
si soy capaz
a ver
como se puede poner
esto aquí
no sé
como se puede poner
quería ponerla
aquí
ahí
la vamos a poner ahí
porque vais a ver
que es súper útil
tener la terminal ahí
siempre abierta
y ejecutándose
de hecho vamos a poner
mpn run test
para ejecutar el comando
de testing
y ahora obviamente
me debería petar
así que ya empezamos aquí
con nuestro tdd
maravilloso
desde cero
y poquito a poco
ya tenemos el test
que nos está fallando
y cuál es el test
que está fallando
que es lo que nos está diciendo aquí
bueno lo que nos está diciendo aquí
justamente es que le falta un test
o sea tampoco es que estamos haciendo
absolutamente nada
así que vamos a hacerle caso
no dice
no hemos encontrado
un suite
found
in file
no sé qué
bueno pues lo primero que tenemos que hacer
es escribir un describe
aquí directamente ya me ha importado
vtest
aunque voy a cambiarlo a
common.js
ahí a
en más script module
vale
vamos a hacer esto
from aquí
y de hecho en los archivos
en el package.json
voy a decirle que es type module
para asegurarnos que podemos utilizar los imports
y todo esto
vale
ahora que ya tenemos esto
quito esto
vale
tenemos el describe
vamos a poner fishbush
guardamos los cambios
y ya vemos que ha cambiado
el error
sigue petando
pero ha cambiado el error
¿qué es lo que
para crear fishbush?
no sé si sabéis lo que es
pero yo tengo por aquí el enunciado
os lo voy a explicar
este el otro día lo hice
en un reel
es un programa
que al pasarle
en este caso
vamos a hacer un programa
una función
vamos a poner
escribir una función
una función
que al pasarle un número
tiene que mostrar fish
si es múltiplo de 3
muestra bash
si es múltiplo de 5
muestra fishbush
si es múltiplo de 3
y de 5
y en cualquier otro caso
muestra el número
si no es múltiplo
de ninguno de los anteriores
vale
es un ejercicio muy sencillo
pero lo vamos a resolver
con tdb
paso a paso
así que
venga
vamos a darle
por lo tanto
¿qué es lo primero
que podríamos pensar
que queremos hacer aquí?
podríamos decir
bueno
lo primero ya
es que quiero que devuelva
no
no
te estás adelantando
lo primero que querríamos hacer
porque así es como funciona tdd
al menos
el que deberíamos hacer bien
tendríamos que decirle
que debería ser una función
should be a function
fishbush
debería ser una función
y ahora me diréis
menuda chorrada
yo os voy a explicar por qué
vale
vamos a esperar que
expect fishbush
que sea una función
de hecho este expect
lo vamos a poner aquí
guardamos los cambios
vale
y aquí podemos ver
que está petando
dice
porque me esperaba
que undefined
fuese una función
alguien dirá
ostras
pero si era evidente
¿no?
claro que es evidente
pero de eso se trata
de
siempre tenemos que estar en rojo
siempre
o sea
primero rojo
antes de escribir
código en producción
así que
bueno
pues lo que tenemos que hacer
es que primero
no tenemos la función
ahora sí
vamos a crear la función
así que vamos a crear aquí
una función
y le vamos a llamar
fishbush
fishbush
vale
ahora fishbush
vamos a guardar los cambios
lo tenemos en verde
perfecto
pues ahora
podemos continuar otra vez
ahora
ahora que ya sabemos
should be a function
¿qué es lo que deberíamos
devolver con fishbush?
ahora podríamos pensar
qué es lo que tiene que devolver
cómo tiene que funcionar
una cosa que podríamos pensar
realmente es
mirando esto
escribir una función
que al pasarle un número
o sea ya nos está diciendo
que debería tener
en cuenta
que le vamos a pasar
un número
o sea
¿qué significa esto?
una cosa que podríamos ya tirar
directamente
antes incluso de escribir
es que
aparte de ser una función
debería ser
should throw
o sea debería petar
if not number
is provided
as parameter
o sea lo primero
que podríamos mirar ya
en lugar de meternos
con el tema
de la funcionalidad
es mirar
que si no
si el número
que se le
si lo que está pasando
no es un número
que pete directamente
entonces de esta forma
ya no vamos a
antes de meternos
con el código
ya sabemos
ostras vale
es que necesita un número
así que esperamos
que al ejecutar
fishbush
al ejecutarlo
vamos a decir
to throw
vale
ojo aquí
que esto es interesante
para hacer que esto
funcione bien
el expect del tal
hay que poner aquí
que ejecute una función
porque si no estarías
ejecutando la función
directamente
yo si hago esto
vale
si haces esto
directamente
aquí
lo que estamos haciendo aquí
es ejecutar la función
directamente
de hecho lo vamos a ver
voy a guardar los cambios
ves
y ya me está petando
dice expected undefined
to be a function
vale
lo que está pasando
por aquí
es que ya está
ejecutando esto
y no está dejándole
cagar el throw
así que
vamos a hacer aquí
esto
así
vale
y ahora sí
expected function
to throw an error
ahora sí que tenemos bien
el test escrito
pues tenemos que
hacer que hagan
throw del error
así que vamos a ver
tenemos aquí el parámetro
el number
le dañemos el código
tenemos que hacerlo
y decimos
si type of number
no es un number
entonces
throw new error
y ahora podría decir
esto
o sea
throw new error
y ya está
o sea
no hace falta que haga nada más
aquí podría poner un error
aquí podría hacer
todo lo que me dé la gana
pero no
porque al final ya
en realidad ya ha pasado el test
yo con esto ya ha pasado el test
no tengo que hacer más
no debería hacer absolutamente nada
¿por qué?
porque ya estaría haciendo código de más
ahora
si yo quiero
si me gusta
si quiero
que el error
tenga más información
en realidad lo podríamos mirar
¿sabes?
podría decir
if not the numbers
prove it as a parameter
pero ahora debería hacer
un it
dice
should throw
a specific
error
message
if not numbers
provided as a parameter
¿vale?
y aquí lo que podríamos decir
to throw error
y a ver si ahora me acuerdo
to throw
expected
vale
vamos a ponerle aquí
que ponga algo de number
¿vale?
y ahora aquí decimos
más number
más vía number
parameter
parameter
provided
más vía number
o le podemos pasar justamente
el mismo string
¿veis que ya estamos haciéndolo
como en crescendo?
lo estamos haciendo como en crescendo
¿ya?
¿sabes?
que estamos haciéndolo
o sea
antes de hacer esto
perdón
que he hecho esto antes
tendríamos que hacer esto
vemos que ahora nos peta
porque tenemos el to throw
y ahora tenemos que asegurarnos
que está haciendo un throw
de un error en concreto
y nos dice
vale
es que esperaba
que este error
incluyese
parameter provide
de muy bien number
y ostras
claro
es que entonces
este
lo tenemos que poner aquí
¿no?
y esto
ya empieza
ya empieza aquí un poco
la rueda de ir dándole al coco
¿no?
y tendríamos que pensar
bueno
¿qué pasa si nos pasa un notan number?
vale
pues podríamos probarlo aquí
¿qué pasa si pasa un notan number?
¿qué es lo que esperaría?
pues si esperaría
claro
ahora ya sé que si hago esto
should throw
specific error message
if
notan number
is provided
¿veis que ya estamos pensando
en los casos concretos?
entonces ¿qué debemos decir?
parameter provided
más via number también
vamos a hacer lo mismo
guardamos los cambios
bueno y en este caso
le tenemos que pasar aquí
el none
¿vale?
y ahora nos está petando
ahora hemos escrito bien el test
y nos dice
vale
es que debería hacer un throw del error
¿qué pasa?
que el notan number este
no lo hemos tenido en cuenta
así que tendríamos que mirar aquí
¿vale?
if
number
creo que es
number.isnone
entonces vamos a poner
throw new error
lo mismo
guardamos los cambios
¡pam!
así
así todo el rato
¿vale?
así todo el rato
podríamos estar aquí todo el día
pero vamos a hacer rápidamente
como feedback es muy sencillo
voy a intentar ir bastante rápido
de cómo vamos a llegar a la solución
¿vale?
cómo vamos a llegar a la solución
utilizando TDD
primero
vale
vamos
podéis
como ejercicio
os dejo que os pongáis
aquí con los errores
y vayáis mirando todos los casos
¿vale?
de hecho podéis hacerlo antes
lo podéis hacer después
en este caso lo importante
es que cada vez que hagamos un test
que esté en rojo
hagamos la solución
¿qué podríamos hacer aquí en el FISBAS?
fíjate que dice
muestra FIS si es múltiplo de 3
BAS si es múltiplo de 5
vale
muestra el número
si no es múltiplo de ninguno de los anteriores
por lo tanto
should return 1
if number provided is 1
¿no?
o sea si es 1
perfecto
pues esperamos que FISBAS
sea 1
tiene que ser 1
así de fácil
guardamos los cambios
nos peta
otra vez
rojo
vale
no pasa nada
pues vamos a darle
vamos a darle otra vez
¿qué es lo que tenemos que hacer?
aquí
habría diferentes opciones
alguien podría decir
bueno
me voy a poner ya
a hacer aquí la lógica de negocio
que no sé qué
no sé cuánto
a ver
vamos a calmarnos
tenemos que hacer que pase este test
¿sabéis lo que voy a hacer?
return 1
¿por qué?
porque esto hace que pase el test
ya está
así de fácil
fácil y rápido
¿vale?
esto hace que funcione el test
no hace falta
Christian
no hace falta envolver
este
esta función
esta ejecución
esta ejecución
solo hay que hacerla aquí
porque esto es un throw
y necesitamos ver
que esto
hace un throw
realmente
vale
¿por qué he hecho esto?
alguien dirá
ah ¿por qué he hecho esto?
o sea ¿qué dices tío?
¿por qué has devuelto un 1?
¿estás tonto?
esto es TDD amigos
hay que escribir el mínimo código posible
para que pasen nuestros test
y en todo caso
los test
nos guiarán a la solución
¿vale?
esto es súper importante
por eso os digo que
por muy sencillo que sea
el caso
vais a ver que
los test
son los que nos van a guiar
¿por qué?
porque ahora digo
vale
entonces si hago un short return
2
if number provided
is 2
¿vale?
tenemos ya
nos está guiando
nos está guiando el test
¿por qué?
porque si hago un FISBUSH 2
tiene que ser 2
vale
voy a guardar los cambios
y esto peta el test
otra vez
ok
entonces
¿qué tengo que hacer ahora?
ahora
fijaos
podría hacer
if number
es 1
return 1
if number
es 2
podría hacer esto ¿verdad?
pero ¿qué pasa?
que he escrito más
he escrito más código
más código
que el que realmente
tendría que escribir
si realmente llegase
a una solución
que podría
hacer que los dos tests
pasen
ok
entonces
return 1
no
vamos a hacer
un return number
porque en este caso
ahora tiene sentido
que hagamos un return number
ahora sí que estoy viendo
un patrón
pero habéis visto
que el patrón
lo hemos visto
realmente gracias al test
y no nos hemos adelantado
esto es súper importante
en TDD
esto es un ejemplo
muy sencillo
pero lo vais a ver
constantemente
que esto pasa todo el rato
así que guardamos los cambios
vale
perfecto
pero vamos con el siguiente caso
porque ahora
ahora debería devolver
fees
if number provided
is 3
así que vamos a ver
qué pasa ahora
vamos a ver
expect
cuando le pasamos 3
debería ser fees
vale
no se está petando
porque con el 3
debería ser fees
¿qué tenemos que hacer?
obviamente
si el número
es 3
entonces devolvemos fees
porque esto es el caso
este es el caso
que tiene todo el sentido
del mundo
tiene todo el sentido
del mundo
si el número es 3
voy a devolver fees
y me pasa el test
pero si estamos en el caso
de que muestra fees
en los múltiplos de 3
vamos a seguir haciendo
otra vez esto
¿no?
vamos a hacer esto
y vamos a decirle
vale
vamos a devolver fees
si el número provided
es
múltiplo
múltiplo
of 3
y por ejemplo
podría ser el 6
¿no?
podría ser el 6
podría ser el 9
podría ser el 12
en todos estos casos
necesitamos
asegurarnos
que sea fees
o sea
vamos a poner
3 pruebas
o sea
es un test
pero vamos a hacer
que peten diferentes pruebas
¿por qué?
porque si pusiese el 6
otra vez podría decir
bueno
si pongo otra vez
el 6
entonces ya lo devuelves
no
bueno
vamos a poner
múltiplos
múltiplos de 3
el 6
el 9
el 12
vamos a guardar los cambios
y obviamente
me peta
porque esperaba
que el 6
me devolviese
el fees
yo ahora
podría decir
vale
si el número
es 6
que me devuelva
el fees
lo vuelvo a guardar
y fíjate que me vuelvo a petar
¿no?
aquí estamos justamente
otra vez
el tema de
estamos viendo
el problema
de
esta solución
no me funciona
porque aunque sepamos
que vamos a tener que cambiar el código
por entender el problema
necesario hacer esto
no es un poco ineficiente
para nada
es ineficiente
o sea
entiendo que muchas veces
vas a creer
porque una cosa es lo que tú creas
otra cosa es lo que realmente pase
que estás entendiendo totalmente
el problema que hay detrás
pero lo cierto
es que a lo mejor
estás entrando
estás viciándote
en la solución
porque al final
lo que tienes que hacer justamente
es que
es probarlo
es probarlo
y tú te estarías adelantando
y te estarías saltando
pasos
que están haciendo
que compruebes realmente
con un test
lo que estás haciendo
así que vamos
al final
que si no quieres utilizar TDD
pues no hagas TDD
pero para hacerte TDD
tienes que hacer esto
¿vale?
es lo que tienes que hacer
bueno ya vemos que el test
no me está pasando
si pienso un poco
necesito que numbers
sean múltiplos de 3
¿vale?
así que decimos
múltiplos de 3
vamos a devolver fees
guardamos los cambios
y ahora sí que funciona
esto mismo
fijaos
ahora vamos a hacer otra cosa
que es bastante importante
del TDD
ahora
he pasado ya
ya tengo un caso
fijaos que
ya tengo este caso
luego
ahora vamos a hacer
justo después de este
una prueba
mucho más difícil
y vais a ver
que vamos a seguir
exactamente lo mismo
exactamente lo mismo
y os va a resultar
fácil y todo
y mira que es complicado
el algoritmo
que vamos a hacer
vale
vamos a decir
debería devolver 4
si el number provided
es 4
vamos a poner este caso
a ver que pasa
¿vale?
fees bus 4
tuvi 4
guardamos los cambios
fíjate que he guardado
los cambios
y se ha puesto en verde
o sea
no ha petado
no ha habido ningún tipo
de problema
no ha petado
¿qué pasa con esto?
esto lo que significa
es que
una de dos
o el test que hemos hecho
no es válido
o sea
no nos está aportando nada
o sea
aunque la implementación
no estuviese hecha
pues que a lo mejor
no es muy útil
porque por ejemplo
podrías hacer un test
de esperar que
fees bus
yo que sé
que se devuelva
un booleano
o que devuelva
un número
un tipo número
ya no tiene mucho sentido
ya está cubierto
o puede ser
que una de las lógicas
generales
que ya hemos hecho
en nuestro algoritmo
ya esté satisfaciendo
el test que queríamos hacer
así que
en este caso
lo mejor es estudiar
lo que hemos hecho
y aquí
yo personalmente diría
vale
este caso en realidad
ya está cubierto
no me añade nada
así que esto
lo borraríamos
¿vale?
si hacemos un test
que directamente
nos pasa en verde
lo que deberíamos decir es
vale
voy a ver
si realmente esto
tiene sentido
o no tiene sentido
lo mismo pasaría
por ejemplo
un error muy común
que veo con la gente
que utiliza TDD
es que la gente
cree que todos los tests
que has creado
los tienes que dejar
y no es así
por ejemplo
aquí hemos creado un test
que era para ver
si era una función
este test
ya no tiene sentido
porque es obvio
que este test
está cubierto
en el resto de test
por lo tanto
este test
una vez que nosotros
hemos visto
los tests
que hemos creado
vamos a ir quitando
los tests que son redundantes
como este
lo puedes comentar
si quieres
lo puedes eliminar
lo que tú quieras
yo lo voy a comentar
por si subimos este código
para que veáis los tests
que hemos ido haciendo
¿vale?
entonces voy a dejar este
y este
este test
ya está cubierto
en el algoritmo
¿vale?
y en este caso
vamos a ver
que este test
tampoco tiene ya sentido
este test
lo hemos desactivado
posteriormente
porque es redundante
hay que tener
hay que tener en cuenta eso
¿vale?
los tests se tienen que ir apagando
se tienen que ir eliminando
cuando dejan de ser
cuando dejan de ser útiles
este test ya no aporta
absolutamente nada
esto es un error muy común
que veo que la gente
deja ahí los tests
para siempre
y no tiene ningún tipo de sentido
muy bien
ahora
obviamente necesitamos
el caso de
módulo 5
¿no?
¿vale?
should return bus
if number provided
is multiple
of 5
¿no?
vamos a poner esto
y aquí esperamos
que el fix bus de 5
voy a quitar estos
solo ponemos un caso
guardamos los cambios
me peta
esperaba que 5
me devolviese bus
¿vale?
perfecto
¿qué puedo hacer?
a ver
aquí obviamente
no hace falta
podríamos hacer esto otra vez
podríamos hacer esto otra vez
¿vale?
podríamos hacer esto
y empezar otra vez
pero obviamente
ya hemos visto
cuál es la lógica
que justamente tiene
que vaya retornando
¿no?
cómo lo vamos a hacer
esta lógica
la hemos entendido
por lo tanto
la podríamos añadir
la podríamos añadir
si no
lo que podríamos hacer también
es hacerlo igualmente
¿eh?
podríamos hacer esto
y volver otra vez
lo tenemos en verde
añadimos todos estos
hacemos que pt
¿vale?
y aquí teníamos 5
10
bueno 5 no
teníamos aquí
10
15
20
múltiplos
de 5
y vamos a poner aquí
provided is 5
que me he copiado antes esto
y estos son bus
¿vale?
esto es bus
bus
y bus
vale
entonces nos petaría
y ahora sí
podríamos decir
vale pues vamos a añadir
aquí el módulo
muchas veces el tdd
la gente puede decir
ah es que esto es un rollo
bueno
las cosas parecen
que es un rollo
pero no es un rollo
en realidad
should return
bus
puesto aquí
bus
if a number
a ver que la he liado
¿veis?
la he liado
fish bus
if number probably
this is multiple
ah mira
mira
aquí tenemos
aquí tenemos un tema
¿no?
dice should return bus
if number probably
this is multiple
de 5
pero resulta
¿veis?
justamente
el 15
es múltiplo
de 5
y múltiplo
de 3
y justamente
aquí
hemos tenido
este error
en el que
en el que
el test
nos ha librado
en este caso
a ver
en el desarrollo
nos ha librado
yo no me había tenido en cuenta
ni siquiera había caído
y ahora
gracias a esto
he dicho
ostras
pero me sigue petando
justamente ¿no?
así que
en este caso
vamos a ver
ostras
¿qué podemos hacer?
en realidad
este caso
lo tenemos
aquí
dice
muestra
fish bus
si es múltiplo
de 3
y de 5
ahora que hemos visto esto
realmente
este caso
está mal
porque en este
no deberíamos esperar
bus
deberíamos esperar
otra cosa
vamos a poner
estos casos
que son los que tienen sentido
y ahora sí
vamos a añadir
it
should return
fish bus
if number
provided
is multiple
of 15
¿vale?
vamos a poner esto
esperamos
que fish bus
15
to be
fish bus
¿vale?
ahora haremos justamente
también el
haremos un refactor
¿vale?
para que veamos
como
porque tiene sentido
el tema del refactoring
que hemos visto
con el tema de los test
¿ok?
vale
obviamente
ahora me peta
y me dice aquí
esperaba fish
pero tú decías
fish bus
y dice
hostia
que verdad
obviamente
midu
múltiplo de 3
y de 5
no 15
es que múltiplo
de 3 y de 5
es de 15
¿no?
o sea
múltiplo de 3
y de 5
tiene que ser 15
no hay otro
¿eh?
así que eso sería
el tema
vale
entonces
ya que tenemos esto
deberíamos volver aquí
y fíjate que aquí
ya nos va a salvar
nuestros test
¿por qué?
uno de los errores
más comunes
que veo en el fish bus
es que la gente dice
vale
pues ya está
vale
o sea
que tiene que ser
múltiplo de 3
y de 5
bueno
pues vamos a poner
esto aquí
por ejemplo
¿no?
venga
he guardado
y esto
me sigue petando
me sigue petando
podríamos hacer esto
o podríamos hacer
decir
vale
que sea múltiplo
de 15
por ahora voy a hacer
que sea múltiplo
de 3
y de 5
pero esto
es que esto está mal
esto está mal
porque justamente
está entrando
en el primer if
y por lo tanto
ya no entra en este
¿qué significa?
que nos ha salvado
nos ha salvado el test
habríamos puesto
pensando que lo hemos hecho bien
si no lo hubiéramos probado
seguramente esto
se nos hubiera colado
esto lo tenemos que mover
arriba
que sea el primero de todos
ahora guardamos
y ahora que hemos guardado
y el test
lo tenemos justamente
en verde
lo que podemos pensar es
ostras
vale
¿cómo puedo refactorizar esto?
el number 3
vale
0
perfecto
¿cómo puedo hacer esto?
vale
pues lo que podríamos hacer
es decir
bueno
pues vamos a decir
15
porque es el múltiplo
de 3 y de 5
tiene que ser 15
voy a guardarlo
el test
me funciona correctamente
y ahora puedo empezar
a refactorizar
de hecho
podríamos empezar
a refactorizar más
una cosa que no hemos hecho
y que deberíamos haber hecho
y ahora con los test
lo podemos hacer
es que podemos refactorizar
por ejemplo
de sacarlo
a una carpeta source
y aquí vamos a decir
fishbus.js
y esto
lo hemos hecho aquí a fuego
pero no tiene sentido
que esté aquí
así que lo vamos a poner aquí
voy a guardar los cambios
guardo los cambios
me está petando
me están petando los test
los test
me están ayudando
justamente
lo que
lo que necesito saber
ostras
que es que me está petando
¿por qué?
porque todavía no lo he hecho
vale
no pasa nada
estoy refactorizando
voy a hacer que mi código funcione
importamos el módulo
vale
fishbus
lo guardamos
me pasan otra vez los test
vamos a seguir refactorizando
por ejemplo
viendo estos if
que tengo aquí
pues pensando
ostras
cómo podría mejorar un poco
esto
una cosa que se me ocurre
que podríamos hacer
si fuese esta lógica
podríamos tener aquí
los multiplies
y diría
vale
voy a intentar extraer esto
lo podrían hacer con un switchcase
pero un switchcase
es un poco rollo
así que voy a decir
vale
el 3 tiene que dibujar fish
y el 5 tiene que dibujar bus
vale
perfecto
lo que podríamos hacer
es tener un object entries
vamos a recuperar
todos los multiplies
y ahora aquí
vamos a tener un for each
vamos a hacer
pam pam
for each
y en el for each
vamos a tener
como primer valor
justamente
el multiplier
y como segundo valor
la palabra que queremos poner
vale
y ahora
en lugar de hacerlo aquí
que había hecho todo esto
lo que podemos hacer
es tener una variable aquí
que le voy a llamar
output
vamos a empezar
con un string vacío
y aquí
voy a petarme todo esto
que ya no lo quiero hacer así
y voy a decir
vale
pues a ver
que podría ocurrir aquí
pues que si el number
el número que le hemos pasado
por parámetro
es divisible
entre el multiplier
en el output
le voy a concatenar
la palabra
vale
vale
ahora voy a guardar
los cambios
pum
me está petando
ostras
he hecho mal el refactor
que me ha pasado
estoy mal
a ver
voy a revisarlo
menos mal que tengo
todos estos test
que sabía
que tenía que funcionar
me han salvado la vida
porque casi la lío
vale
me está diciendo
que el output
no lo estoy utilizando
ostras
voy a poner aquí output
a ver si esto lo arregla
mmm
no lo arregla
de hecho
algunos sí que funcionan
y otros no
madre mía
que nervios
pero menos mal
que los test
me han vuelto a salvar
porque es que si no
podría estar durmiendo
ahora mismo
en la calle
despedido
menos más
vale
ahora digo
ostras
¿por qué me está pasando esto?
bueno
pues podríamos mirar
output
¿qué pasa?
que cuando el output
es vacío
significa que no ha cambiado
ningún fish
vale
ok
entonces si es vacío
voy a devolver el number
y si no
el output
vamos a guardar
vamos a guardar los cambios
vale
y ahora sí
me están pasando
todos los test
moraleja
no refactorizar
no
moraleja
gracias a los
gracias
a los test
hemos podido
refactorizar
y pese a que hemos
hecho un refactor
que no lo podíamos
hacer de golpe
a lo mejor
refactor
¿no?
el refactor
nos ha funcionado
al final
pero
durante el proceso
del desarrollo
lo que ha ocurrido
es que nos ha fallado
pero los test
nos han salvado
porque gracias a los test
nos hemos dado cuenta
que esto
no era
el refactor correcto
¿vale?
así que eso
eso es lo importante
vamos a poner esto por aquí
en
ah no
que me lo pone en la misma línea
la madre que parió
vale
voy a quitar esto
para que se vea bien
así que con este refactor
que hemos hecho justamente
veo más simple los if
al menos en este caso puntual
no me funen
pero a ver
a ver
que era un refactor
que
muchas veces
la gente como
se queda con
a ver
estamos como apuntando a la luna
te digo mira la luna
y te apuntan
y mira el dedo
a ver
en este caso
no es tan importante
estamos aprendiendo TDD
no es importante la implementación
de hecho lo bueno de la implementación
es que la podemos refactorizar
la implementación
lo bueno es que ya tenemos los test
sabemos que funciona nuestra batería
de pruebas
y la podemos refactorizar
tantas veces como queramos
luego
que prefieres un if
un switch
que prefieres un objeto
todo tiene sus cosas buenas
y sus cosas malas
y depende
de la solución
por ejemplo
este código
es mucho más extensible
que un if
un switch
o lo que tú quieras
por ejemplo
te reto
ya que lo quieres hacer
con un if
te reto
a que ahora
añadas un número
por ejemplo
con el 7
que haga guf
y te reto
a que le hagan los test
y tal
ahora mismo
todos los test pasarían
ves
no hemos hecho TDD
pues que pasaría
si decimos
vale con el 7
te reto
a que lo hagas con if
que ahora aquí digas
vale con el 7
por ejemplo
vamos a poner el fish
y verás que los if
o los switch
al final no son tan
no son tan
extensibles
en este caso
vale
ponemos guf
el provide de test 7
y ponemos aquí guf
y le decimos que es 7
esto obviamente va a petar
vale
o debería petar
ah espérate
hay veces que se
si se os queda a veces penchado
que no pasan los test
o sea que no se refresca
le dais a la h
y le dais a rerun
porque a veces
se queda tonto
pero veis
ahora dice
con el woof
debería ser el número 7
ha petado el test
pues vamos aquí
y ya
lo único que tenemos que hacer
es añadirlo aquí
y ya funciona automáticamente
sin ningún tipo de problema
sin tener que hacer
absolutamente nada
tendrías que escribir
más y más if
en el caso de que quieras
extenderlo a más casos
totalmente incorrecto
no tiene por qué
pero bueno
Ariel Castro
o sea
eso es bastante
opinionado
el hecho de
tendrías que escribir
más y más if
en el caso de que quieras
extenderlo a más casos
de hecho
de nuevo
te reto también
a que lo hagas
Ariel Castro
imagínate que tenemos
el ejercicio con los if
y yo te digo
ahora hay que añadirle el 7
te vas a dar cuenta
que con los if
no escala
porque empiezas a tener
múltiplos entre ellos
por ejemplo
igual que tienes
el fish bus
cuando es 15
también te puedes encontrar
el 21
que es múltiple
de 3 y 7
y deberías enseñar
un fish woof
con if
no tienes cojones
a hacerlo
no tienes
así te lo digo
y si añades uno más
ya estás loco
pero bueno
que si te quieres divertir
haciéndolo
lo puedes hacer
porque si no
si no
los if no
no escalan al final
pero os vais a volver loco
con if
¿qué pasó con el 15
en el refactor?
¿qué pasó con el 15
en el refactor?
no sé qué pasó
¿qué pasó con el 15?
que el 15
está ya cubierto
el 15
es múltiplo de 3
y de 5
como aquí estamos
haciendo un for each
lo que hacemos
es que primero
es múltiplo de 3
y luego es múltiplo de 5
como estamos concatenando
en el string
al final
lo que tendrías aquí
es 15
o sea
tendrías el fish bus
porque los concatena
por eso es una solución
que escala súper bien
porque no tienes que hacer los if
los switch escalan mejor
bueno
te reto también
a que lo hagas
no me retenido
eso te di la razón
ah perdón
te entendí mal
entonces
pero bueno
verás que
con un switch
tampoco escala bien
porque te vas a volver loco
a la hora de
hacer estos múltiplos
múltiples
¿sabes?
por ejemplo
el 3 y el 7
el 5 y el 7
te volverías
más gara
no
al final
no costaría
no funcionaría
funcionaría muy bien
el caso
es solo hay que tener en cuenta
el orden de diccionario
que haces
eso sí
el orden importa
podrías utilizar también
un map
para aseguraros
y ya está
midu
podrías explicar
el object entries
bueno
object entries
lo hemos explicado aquí
unas cuantas veces
pero básicamente
tú tienes un objeto
A
hola
B
adiós
haces object entries
y esto lo que te hace
es devolverte
un array
un array de arrays
donde por cada posición
del array
la primera posición
tienes la llave del objeto
y en la segunda posición
el valor del objeto
de esta forma
estamos haciendo justamente esto
object entries
y aquí
lo que recuperamos
en la primera posición
es el multiplicador
y en la segunda posición
la palabra
y ya está
pi pi pi
si probamos con el 21
devolverá fishWolf
debería
podríamos probarlo
por ejemplo
podríamos ponerlo
claro
llega un momento
hay otro error
bastante típico
que la gente dice
ah es que claro
has hecho algo
que hace
mira fishWolf
ahora ha funcionado
perfectamente
hay un error muy típico
también de la TDD
que hay gente que dice
ah es que has hecho algo
o sea
ahora por ejemplo
este test
ya no aporta valor
en el desarrollo
porque realmente
ya está cubierto
este caso
pero es que está cubierto
porque lo hemos hecho
automáticamente
lo importante es que
lleguemos de forma natural
no forzada
eso es lo importante
vamos a hacer otro
mucho más difícil
¿vale?
claro
midu deberías verlo
fallar el fishWolf
pero es que al final
llega un momento
que no es así
¿por qué?
por ejemplo
imagínate que digo
no es que ahora voy a mirar
el 8
voy a mirar
llega un momento
que la lógica
la has hecho y ya está
y no puedes hacer nada
¿sabes?
no le puedes hacer nada
a ese aspecto
estaría guay meter
random test
sí la verdad es que sí
pero bueno
al final
vamos a meternos
con TDD y tal
en RIA
¿qué se testearía?
pues luego lo miramos
¿no?
Petronini
vamos por partes
a ver qué tal
venga
vamos con otro ejercicio
y este va a ser
bastante más difícil
y vamos a ver
cómo lo vamos a hacer
porque vais a ver
vais a alucinar
mira
aquí teníamos
en AppNGS
que es una página
que tenemos de
sí es súper
súper rápido
súper súper rápido
VTest
es increíblemente rápido
entonces
aquí tenemos
retos de JavaScript
y uno
fijaos que es
muy difícil
muy muy difícil
la verdad es que
chungo
es difícil
no está mal
o sea
es un test
difícil
vamos a verlo
estamos en la fábrica
Santa Claus
porque bueno
la AppNGS es de diciembre
creando regalos
como si no hubieran mañana
pensábamos que no íbamos a llegar
pero
Wolf Bezos
ha tenido una idea genial
para aprovechar las máquinas
y optimizar al máximo
la creación de regalos
la configuración de las máquinas
es un string
¿vale?
la configuración de las máquinas
es un string
el de la fábrica
vas a flipar
lo fácil
que nos va a salir
con test
con TDD
nos va a salir
mucho más fácil
que pensándolo sin TDD
y aquí es donde vais a ver
la diferencia justamente
¿vale?
podemos reconfigurar la máquina
este string
para que haga otro regalo
podemos cambiar
cada carácter por otro
pero esto tiene limitaciones
al reemplazar
el carácter
al reemplazar el carácter
se debe mantener
el orden
no se puede asignar
al mismo carácter
a dos letras distintas
esto es lo mejor
lo veremos aquí
con los casos
que tenemos de prueba
lo vamos a ver aquí
entonces
ya decimos
que cuando reemplazas
un carácter
debe mantener el orden
y un mismo carácter
no se puede asignar
a dos letras distintas
y claro
la longitud del string
de un regalo
al otro
tiene que ser lo mismo
necesitamos
una función
que nos diga
si podemos reconfigurar
una máquina
para que de un regalo
pueda pasar
a fabricar otro
según estas reglas
que hemos mencionado
¿vale?
vale
aquí tenemos un caso
por ejemplo
de este string
val
podemos pasar
a lib
¿por qué?
porque el string
tiene las mismas medidas
porque cada letra
la b se transforma en l
la a se transforma en i
la l se transforma en b
o sea
¿veis?
aquí tenemos la transformación
esto funcionaría
este por ejemplo
no funcionaría
¿por qué?
porque la c se transforma en j
la o se transforma en u
y ya hemos visto
que la o
debería ser la u
pero en cambio
aquí dice que es la n
por lo tanto
esto no se podría reconfigurar
¿vale?
que como sois
¿eh?
mira
aquí pone bar
en esta solución
pone bar
porque alguien me dijo
no me funciona mi solución
porque no sé qué
no sé cuánto
y pegué su solución
para ver si funcionaba
madre mía
¿eh?
madre mía
¿cómo estáis?
¿cómo estáis hoy?
la leche
que estáis ahí
ñiñiñi
estáis picando piedra
¿eh?
cago en la leche
esto es que muchas veces
mucha gente me dice
es que no sé
por qué no me funciona
mi solución
y tal
entonces
pues me pego su solución
y veo lo que
esta no es la solución
que tenía yo
pero se guarda las soluciones
¿vale?
es como
yo
yo soy el que estáis
pero si sois vosotros
si sois vosotros
que estáis ahí a tope
cago en la leche
no me dejan pasar ni una
este es tu héroe
el que usa bar
cago en la leche
bueno
ahora compararemos la solución
de TDD con esta
ahí está
esa es la idea
vale
tenemos un montón de casos
¿no?
Xbox
este tampoco va a funcionar
porque como podéis ver
las letras no siguen
el mismo orden
o sea la X se transforma en X
la B
no se puede transformar en X
y además
el orden de transformación
tampoco está bien
y en este caso
sí que se podría
¿ves?
true
y en este caso
no podría
porque no se puede hacer la transformación
bueno
ya hemos visto un poco
los casos
vamos a hacerlo
desde
de hacer
vamos a hacer esto con TDD
si os parece
vamos a empezar con el test
le voy a llamar
can configure.test.js
y ahora
vale
estoy enseñando la pantalla ¿no?
vale
digo a ver si no estoy enseñando la pantalla
y la voy a liar parda
y entonces sí que me vais a funar
que
venga
ya me está fallando el test
me está fallando el test
porque dice
no he encontrado ningún test
vale
no pasa nada
yo te lo pongo aquí
describe
y ponemos aquí
can configure
no sé si llamarle
can configure
can reconfigure
vamos a llamarle
bueno
can reconfigure
que pueda reconfigurar
creo que está mejor la reconfigure
¿vale?
voy a poner can reconfigure
le vamos a llamar así al meta
¿vale?
ya tenemos el describe
pero todavía sigue petando
porque no tiene un hit
¿vale?
vamos a poner un hit
un hit
aquí vacío
ahora sí
está en verde
vamos a volver a poner aquí
can reconfigure
should be
a function
que ya sé que esto
os debe dar
mucho coraje
pero esto es tdd
configure
can configure to be
to be
type of function
¿vale?
obviamente me peta
porque no tengo
el can configure aquí
¿vale?
no pasa nada
can configure
creamos la función
y ya está
ahora
¿qué pasa con esto?
deberíamos
tenemos diferentes cosas
que podemos hacer
a mí normalmente
para empezar con tdd
me gusta
mirar el tema
de los parámetros
entonces aquí podríamos poner
por ejemplo
it should throw
if first parameter
is missing
¿vale?
si el primer parámetro
le falta
pues deberíamos
por ejemplo
vamos a poner esto
en este caso
expect
en el can configure
no le estamos pasando nada
esto te debería hacer
un throw
y ahora
guardamos los cambios
esto peta
¿vale?
y vamos a poner aquí
los dos parámetros
bueno
podríamos poner el primero
from y to
pero bueno
vamos a empezar
con el primero
if type of from
o bueno
podemos poner
si es undefined
directamente
si es undefined
throw
new
error
y aquí
from is required
¿vale?
guardamos los cambios
ya están verdes
muy bien
issue throw
if first parameter
is missing
¿vale?
también deberíamos hacer esto
debería hacer throw
si el primer parámetro
is not a string
por ejemplo
¿no?
y aquí le podemos pasar un dos
porque ya hemos visto
que tenían que ser strings
bueno pues
if from
if type of
from
es diferente
a string
throw
new
error
from
is not
a string
¿vale?
guardamos
perdonad
no he hecho que pete
perdón
ahora
peta
¿vale?
y ahora escribimos el código
¿vale?
escribimos el código
ahora podríamos hacer
un refactor
¿por qué?
ya lo tenemos en verde
podríamos refactorizar
y es que en este caso
estamos viendo que
este if
ya no aporta
nada realmente
porque una vez que hemos hecho
este caso
al final
podríamos quitar esto
porque from is required
podemos decir
from is required
o from is not a string
porque si está requerido
también sería un string
tenemos diferentes opciones
pero si lo quitamos
podríamos probar
a ver si todo sigue funcionando
podemos ver que sigue funcionando
y ya está
si queremos quitar código
con este refactor
lo podríamos hacer
o si queremos
devolver
mirar los errores
pues no lo podríamos hacer
deberíamos hacer este tipo de cosas
¿vale?
venga
seguimos aquí
¿qué más queremos hacer?
todo esto
lo deberíamos hacer
obviamente también
con el segundo parámetro
así que
podríamos copiarnos
todo esto
en este caso
lo estoy acelerando
porque si no
estaremos aquí todo el día
así que voy a poner aquí
a
y aquí le voy a dejar
el segundo parámetro
vamos a poner aquí
second parameter
is missing
y second parameter
is not a string
a ver
si esto lo puedo quitar
vamos a poner solo este
de second parameter
is not a string
así que
vamos a poner
que el primer parámetro
es esto
y aquí vamos a poner
que sea
por ejemplo
bueno nada
no le pasamos nada
¿vale?
me peta
porque no está haciendo un throw
no estoy haciendo el check
del segundo parámetro
vamos a añadirlo
¿vale?
if type of to
es diferente a string
throw new error
le decimos que to
is not a string
¿vale?
hay un error
hay alguien que ha dicho
esto con TypeScript
no pasa
pero
sí que pasa
en realidad
sí que deberías
hacer estos tests
y sí que deberías
hacer este código
es bastante importante
porque TypeScript
lo primero
es que TypeScript
es estático
no funciona en runtime
y nada te asegura
TypeScript
no te puede asegurar
que alguien
ejecute este método
sin parámetros
lo que te hace TypeScript
en todo caso
es un chequeo estático
no durante el runtime
¿vale?
o sea que
bastante
sí perdón
que he puesto
can configure
y es
can reconfigure
pero sí
eso es un error
bastante típico
también sobre TypeScript
o sea que
no
TypeScript
necesita
este código
otra cosa
es que gracias
a este código
vas a poder entenderlo
mejor
o sea vas a
te va a decir
no no es que tienes
que hacer esto
porque si no te puedo petar
vale
igual te ayuda
a que evites ese problema
pero este código
es necesario
para TypeScript
¿ok?
¿cómo sabe que es el segundo parámetro?
porque lo he puesto aquí
¿no?
aquí he puesto from
aquí he puesto tu
yo le he puesto ese nombre
y entonces miro el tu
y aquí sabe que es el segundo parámetro
porque sí que se lo estoy pasando
o sea aquí vendría el segundo parámetro
¿no?
aquí
vale
esto sería con el tema
de los parámetros
ya hemos visto
lo he acelerado un poco
¿vale?
ahora vamos
ahora vamos a ver
lo fácil
que va a ser
solucionar esto
haciéndolo
con TDD
y ya hemos visto
que era bastante complejo
¿qué es lo primero
que hemos visto
en el ejercicio este?
hemos visto
que obviamente
no se puede asignar
el mismo carácter
dos letras
la longitud del string
debe ser el mismo
eso me parece
bastante interesante
porque es algo fácil
de que podríamos testear
de hecho
una cosa
que podríamos testear
incluso
es que el can reconfigure
devuelva
nos aseguramos
de que devuelva un boleano
eso sí que sería
a lo mejor un test
que en TypeScript
posiblemente
podrías evitar
pero podríamos decirle
debería devolver
un boleano
y ya está
y luego pues
porque así estaremos
escribiendo el mínimo
código posible
o sea debería decir
it show
return
a bolean
¿vale?
sin importar realmente
cómo se está ejecutando
mientras le estemos pasando
cosas que no peten
mientras le pasemos esto
debería devolver un boleano
guardamos los cambios
me peta
pues aquí vamos a poner
true
y ahora sí
que tenemos este cambio
ahora sí que podríamos
empezar a decirle
¿vale?
pues tiene que ser false
en el caso que
por ejemplo
vamos aquí
y vamos a poner
it should
return
false
esto es un caso
que hemos visto
¿no?
por lo tanto
si can reconfigure
si aquí tenemos
a, b, c
y en el segundo
tenemos de, e
esto debería
debería ser false
guardo los cambios
y vemos que me peta
pues el primer check
que tengo que hacer
es justamente esto
¿no?
if from.length
es diferente
de tu length
devolvemos false
¿vale?
este es el primero
primer caso
listo
ya tenemos bastantes casos
que nos estamos quitando
luego lo mejor
es que vamos a poder
copiar este código
que tenemos aquí
lo vamos a pegar
en advent.js
a ver si nos hemos pasado
el reto
o no lo hemos pasado
¿vale?
luego
¿qué más tenemos?
luego tendríamos que contar
el número de letras únicas
porque hemos visto aquí
dice
tiene limitaciones
al reemplazar el carácter
se debe mantener el orden
eso lo miraremos después
dice
no se puede asignar
el mismo carácter
a dos letras distintas
esto quiere decir
que las letras
tienen que ser únicas
el número de letras
por ejemplo
aquí hay una letra
dos letras
tres letras
y aquí hay tres letras
también
por lo tanto
se puede hacer el cambio
pero si faltan letras
por ejemplo
aquí tenemos
tres letras distintas
y aquí solo hay
dos letras distintas
por ejemplo
por lo tanto
no vamos a poder hacerlo
y eso
lo vamos a poder hacer
con un poquito
con un test
vamos a revisar
justamente eso
y ya está
así que
vámonos aquí
y decimos
vamos a ver
it should return false
if strings provided
have different number
of unique letters
letras no
letras
ojalá late
late me tomaría yo ahora
un late
vale
así que
hacemos un expect
de can reconfigure
y ahora
vamos a hacer
abc
pero vamos a poner
ddd
por ejemplo
y esto
debería ser
false
también
esto es que son
de la misma longitud
pero tienen
un número de letras
únicas
distintas
vamos a
guardar
vale
pues este
nos peta
pues ahora lo que tendríamos
que hacer es
cómo podemos saber
el número de letras
distintas
en un string
y el otro
bueno
pues esto es bastante fácil
vamos a hacer aquí
un
if
bueno
vamos a hacerlo más fácil
vamos a poner
has
same
letters
eso no es
eso no es
quickhackopilot
has same
unique
same
has same
unique
letters
vale
vamos a utilizar
un
eso que te está diciendo
quickhackopilot
está mal
eso está mal
eso está mal
lo que tenemos que hacer
es hacer un new set
del from
y recuperar el size
y esto
tendría que ser
igual
ahora sí
¿no?
hijackopilot
que te ha empezado a escribir el código
claro
así cualquiera
venga
esto
para el que no lo sepa
vamos a mirarlo aquí
imaginar que tenemos aquí un string
que tiene
y hacemos
new set
de string
y hacemos un size
pues fijaos
que esto nos devuelve uno
y es que en el set
no podéis tener valores repetidos
esto es una forma
en los sets
normalmente se utilizan
muchas veces
esta estructura de datos
se utiliza
o para quitar
los valores repetidos
de un array
o en este caso
para saber
qué letras únicas
tenemos en un string
por ejemplo
si pongo
a, a, b, b, c, c
aquí ahora sería tres
porque tenemos tres letras únicas
si miramos un poquito
el set
¿ves?
tenemos a, b y c
o sea
no puedes meter la misma letra
dos veces
es una forma bastante
bonita
fácil y rápida
que te permite
justamente hacer esto
y el size
te dice
el número
de elementos
que tienes dentro del set
no está mal
esto soy yo
porque ya lo he hecho
un montón de veces
y entonces me lo sé
pero de esta forma
podemos decir
vale
¿cuántas letras únicas
tiene el set
y cuántas letras únicas
tiene el from y el to?
¿tiene las únicas?
vamos a decir
si no tiene las únicas
hacemos un return
false
y ahora me pasa el test
ya que me ha pasado el test
voy a aprovechar
para refactorizar
si te parece
y voy
y como me ha gustado
esto que he hecho aquí
digo ostras
para que quede más claro
voy a sacar la condición
a una constante
es decir
is same length
y vamos a decir
si el from length to length
este
lo voy a sacar aquí
y creo que quedará
más legible
para alguien que vaya
a recuperar el código
guardamos los cambios
sigue en verde
pues el refactor que he hecho
al menos de los test
que he ido haciendo
sigue funcionando
hasta aquí
vamos bien
pero todavía nos falta
¿por qué?
porque hemos visto
que también el orden
era importante
lo hemos visto
en este caso
¿vale?
aquí tenemos
las mismas
o sea
las mismas letras únicas
tenemos también
las mismas transformaciones
pero en cambio
podemos ver
que no funciona
el orden
porque el orden
es distinto
la x es la x
la b
ah no
esto además está mal
por las dos cosas
este sería
no
¿cuál sería el del orden?
¿no tengo un ejemplo del orden?
creo que no tengo un ejemplo del orden
es que aquí
veo que falla
por de las dos cosas
porque también falla
porque no mantiene el orden
o sea el bx
no mantiene el orden
y la x no puede asignarse
a la o
bueno
igualmente
lo vamos a utilizar
para utilizar exactamente
el mismo ejemplo
¿vale?
it
porque
si no petase por una cosa
petaría por la otra
return false
if
¿cómo le decimos esto?
has different order of transformation
o strings
if
strings
has different order of transformation
¿vale?
vamos a hacer un can reconfigure
y vamos a pasarle
el xbox
y aquí
¿cómo era?
xx veo
¿vale?
to be false
vale
es que justamente
no peta
por esto
¿qué podemos hacer?
claro
no peta
porque
debería petar
porque no está mirando
lo del orden
¿qué deberíamos hacer
para que esto
porque
o sea
está petando
porque está haciendo dos transformaciones
a ver
si hacemos esto
¿esto debería petar?
pues tampoco peta
¿no?
tampoco peta
esto debería ser false
ah no
es que esto está bien
esta está bien
lo que deberíamos hacer aquí
en todo caso
sería esto
tampoco
ahora como
como podemos probar este
si tiene un diferente orden
de transformación
pensaba que era
que se
porque este caso
me lo está
se lo está comiendo
xbox
pero obviamente
esto está mal
¿no?
o sea
sí que tiene el mismo número
de letras
ah
debería ser false
pero está siendo
o sea
me está entrando
uno de estos dos
igual la he liado
con alguna
¿no?
a ver
vamos a volver
para atrás un momento
igual la estoy liando
con alguna
y soy yo que
should return false
if string has
different order
of transformation
a ver
¿por qué me está devolviendo
o sea
me está devolviendo
false
ya
has unique
pero esto es
tiene x
b o
a ver
que no estoy viendo
público
el same length
ah
menos mal
¿veis?
¿veis?
es por esto ¿verdad?
es por eso
que me está devolviendo
directamente siempre false
el refactor que he hecho
está mal
muy mal ¿eh?
por mí
muy mal por mí
¿veis?
he hecho esto
y lo he hecho mal
lo he hecho al revés
la lia parda
te lo avisamos antes
es que no puedo
estar por el chat
y por todo
vale
ahora sí
ahora sí
digo joder
es que no tenía sentido
venga pues vamos a utilizar
el ejemplo
y ya está
sí sí la he liado yo
la he liado yo
a ver si este
vale
está en rojo
ahora sí
gracias por avisarme
uy perdonad
gracias por avisarme
perdonad chat
me tengo que pillar un
me tengo que poner aquí
un ipad
ahora quien es rata
yo soy el rata
no te olvides
desactivar el linter
que te canjearon los puntos
otro día
es que a ver
quiero subir este vídeo
a youtube
entonces es un poco raro
al final que ahora
me desactive el linter
y la gente
que tenga que estar pendiente
de eso
creo que lo voy a quitar
los test no te ha ayudado
en estos casos
en este caso
es porque yo la he liado
¿por qué la he liado?
seguramente porque
no hemos puesto un test
que nos debería
nos debería haber
avisado esto
por ejemplo
should return false
if strings provided
have different numbers
y tal
claro
el tema es que
no tenía el different
unique letters
deberíamos haber utilizado
este
dices to be false
pero este me estaba
cubriendo el caso
este de aquí
deberíamos haber
tenemos un corner case
en el que
no nos ha cubierto esto
porque esto tiene
diferente número
de letras
o sea tenemos este
no tenéis
has same unique letters
por eso el test
no ha funcionado bien
entonces lo que
necesitaríamos
es que pese a que
tienen diferentes
unique
diferentes
o sea tienen
diferentes letras
nos tenemos que asegurar
que realmente
el length
vaya a vetar
por ejemplo
tú tú tú
podríamos poner
should return false
if string provided
have different
length
o sea
podríamos poner
mira
el facundo
me lo está diciendo
aap
y ab
porque
las letras
únicas
serían dos
pero la longitud
sería diferente
de esta forma
las letras
únicas
sería
did the shooter
provide
the half
different lengths
even with
different
o same
unique letters
algo así
algo así
debería ser
algo así
y entonces
con esto
ves
ahora sí que me peta
este sería el tema
que funcionaría
¿por qué?
porque si no
estaba entrando
en este caso
y estaba
haciéndolo
pero bueno
ya veis que
incluso
TDD
también es verdad
que TDD
hay una cosa
que es importante
el TDD
no es que te
evite
todos los problemas
al final
es que te los minimiza
no existe
problema cero
en esta vida
obviamente
haciendo estas iteraciones
nos vamos a quitar
muchos corner cases
muchos casos concretos
pero no te los
puede ser que no te los quite
todos
al final es imposible
pero lo que cubres
es mucho mayor
así que
ahí tenemos esto
vale
debería devolver false
si los strings
tienen diferente
orden de transformación
ahora estamos este
no es una bola de plata
exacto
es una medida de seguridad
es como el cinturón del coche
básicamente
como el cinturón del coche
el cinturón del coche
te va a salvar
de que si te caes
por un acantilado
no te vas a matar
hombre no
todavía te puedes matar
pero
te va a cubrir
en bastantes casos
es mucho más peligroso
no vas con el cinturón
es obvio
no es
una bala de plata
pero
te puede salvar la vida
venga
entonces
ahora que tenemos esto
este va a ser
un poco más complejo
aquí obviamente
podríamos empezar
a hacer un if
fácil
en el sentido
de decir
vale
el mínimo código
para hacer esto
sería mirar
que estos dos casos
son diferentes
y luego
escribir la generalidad
¿sabes?
o sea podría decir
si es xbox
devolver esto
y ya está
pero
podríamos hacer
ya sabiendo
cómo va a funcionar esto
podríamos hacer
más la generalidad
podríamos ir buscando
o sea ir guardando
las transformaciones
transformations
que hemos hecho
en el código
y ahora con un for
voy a hacer un for
y luego igual
más adelante
pues lo puedo refactorizar
¿vale?
mira me está escribiendo
aquí el todo
el código
que jacopilot
no sé si será
si estará bien
vamos a intentar
hacerlo nosotros mismos
sin mirar lo que nos dice
¿vale?
vamos a hacer
luego lo podríais hacer
con un reduce
lo podríais hacer
un montón de formas
voy a recuperar
el from letter
que esto es from
from i
y el to letter
vale
to i
vale
ahora que tenemos esto
lo que vamos a hacer
es guardar la letra
store letter
y la letra que te hemos guardado
en las transformaciones
¿para qué?
esto lo que vamos a hacer
es justamente ver
si realmente
la letra que teníamos guardada
en las transformaciones
de esa posición
es la misma
que ya teníamos
¿por qué?
porque así nos vamos a asegurar
que el orden que se está siguiendo
es el correcto
porque si no estaríamos haciendo
transformaciones distintas
así que vamos a mirar
store letter
transformations
y aquí vamos a mirar
que si tenemos
la letra
si tenemos la letra
y además
la letra que tenemos guardada
que hemos guardado
en el objeto
es diferente
a la to letter
esto significa
que no está siguiendo
exactamente la misma
el mismo orden
y en el caso
de que continúe el código
vamos a guardar la letra
el to letter
lo guardamos
porque puede ser
que el to letter
no tenga ninguna transformación
todavía
porque tenemos
un objeto vacío
¿vale?
y esto
debería funcionar
debería funcionar
pero no está funcionando
no está funcionando
porque no me está ejecutando
los test
¿ves?
ahora sí que
me está funcionando
pues con esto
ya lo tendríamos
nos estaríamos asegurando
que estamos siguiendo
justamente
las mismas transformaciones
o sea
vamos guardando
las transformaciones
en un objeto
decimos
vale
esta letra
siempre es esta letra
y así vamos mirando
esta letra
con esta letra
esta letra
con esta letra
esta letra
con esta letra
¿por qué?
porque en lugar de mirar
si esta letra
que está en la tercera posición
tiene que ver con la primera
esto no es lo que queremos
queremos que siempre
la transformación
tenga que ver
con la misma posición
o sea
la posición cero
siempre tiene que tener
esta transformación
entre esta y esta
la transformación
la uno
tiene que tener
este y esta
y así constantemente
y ya está
eso es lo que
y aquí lo que estamos haciendo
es guardar
qué transformación
va con cuál
o sea
la x se transforma
con la b
con la c
y así nos aseguramos
que estamos guardando
bien las transformaciones
y que podemos ir mirando
las posiciones
y si no está guardada
la guardamos después
y ya está
y con esto ya tendríamos
el test hecho
está muy enredado eso
bueno
je de los ríos
o sea
puedes hacerlo
como tú quieras
o sea
lo mejor
je de los ríos
si no lo ves tú
por qué no
anímate
a hacerlo
a hacerlo
tú
o sea
el ejercicio como tal
hombre
es un ejercicio de algoritmia
es muy enredado
pero al final
un diccionario
ya estamos utilizando aquí
es un ejercicio de algoritmia
obviamente
creo que
creo que no está mal
o sea
creo que son
bastante enrevesados
pero es un ejercicio
de algoritmia
de asegurarte
que puedes transformar
un string
por otro
con el enunciado
yo creo que se ve bastante bien
no sé
vale
pues vamos a probar
vamos a hacer la prueba de fuego
vamos a copiar este código
y lo vamos a copiar aquí
fijaos antes
la persona
no me acuerdo
esto no es mi código
pero la persona que hizo este código
pues
hizo dos objetos
luego estaba mirando aquí un for
luego aquí dos strings vacíos
luego otro for aquí
yo
sinceramente
decidme la verdad
¿cuál se entiende mejor?
¿cuál se entiende mejor?
este
que no sé
ya os digo que yo no lo hice
pero me lo copié
me lo pegué y tal
o
o este
porque yo este lo veo
bastante mal legible
yo este lo veo
bastante mal legible
además de que tiene
algunas validaciones
además de que pueden mirar
es la misma
tiene el mismo esto
quizás esta es la parte
que es menos legible
aunque yo esta la entiendo
todavía menos
porque bueno
aparte del nombre de las variables
la parte de las variables
ya bastante compleja
pero el tema es que
al haber resuelto
el algoritmo
de una forma
en el que vas poco a poco
mirando de arriba a abajo
caso por caso
lo que nos hemos asegurado
es que
los casos
los hemos
los hemos ido solucionando
sobre
sobre la marcha
así que
vamos a ver
además
luego tiene este
return true aquí
que está bastante chulo
en cambio aquí
hasta el final
tienes que hacer el return ahí
bueno
vamos a ver si esto funciona
vamos a poner aquí
el from
ahí
vamos a escribir aquí
from to
from to
esto aquí
y todos los test pasaron
así que ya tenemos aquí
que además son menos líneas de código
bastante más verboso
más sencillo
y ya lo tenéis
ahora que
he visto que
sois muy inteligentes
que sois súper buenos
que no sé qué
que yo lo haría
más óptimo
lo que podéis hacer
básicamente
es refactorizarlo
aquí tenéis el ejercicio
tenéis el tdd
y lo podéis hacer
pensando en el test
que ha pasado antes
cuando no estaba implementado
también tiene valor
al final si el test pasa de primera
sobre redundante
muy buena pregunta
clara
a veces sí que tiene valor
puede tener valor
pero lo que tienes que leer
más bien
es decir
lo que deberías tener en cuenta
es
tiene valor
y preguntártelo
si escribes un test
y en realidad
ya está cubierto
por una generalidad
de otro test
entonces no tiene valor
por ejemplo
si tuvieses un test
de si funciona
una multiplicadora
y finalmente
lo que estás haciendo
constantemente
es poner casos
en los test
uno tras otro
al final
llega un momento
que no tiene ningún valor
¿entiendes?
o sea
pero hay veces que sí
porque están cubriendo
a lo mejor un caso específico
que puede romperse
más adelante
o sea
hay que diferenciar
entre uno
que puede añadir valor
y otro que sea una generalidad
que al final
no tiene ningún tipo de sentido
o sea
cuando haces un test
y ya aparece en verde
tienes que preguntarte
ojo
a ver
¿qué ha pasado aquí?
¿realmente
es porque algo está bien?
o sea
¿porque está todo bien?
¿es porque es una generalidad
que ya
o sea
este test
me está aportando valor?
¿o realmente es una generalidad
que está?
o sea
te lo tienes que preguntar
es como un reflac
que debes tener en cuenta
y ya está
simplemente
¿vale?
vale
pues
ya tenemos aquí
el test
o sea
un test más
y ya está
no ha estado mal
y este es uno
de los más difíciles
sinceramente
sinceramente
me ha costado mucho menos
cuando lo hice
cuando yo lo hice
cuando lo hice
al final
me ha costado mucho menos
mucho menos
que la última vez
¿a qué se refiere
lo del orden?
vamos a ver
vamos a ver
lo del orden
aquí tenemos
por ejemplo
este Xbox
Xbox
¿lo puedes transformar
en XXBO?
pues no
no puedes
porque no mantiene
el orden
¿esto qué significa?
que
la X
vale
se transforma en X
vale
pero la B
se transforma en X
esto ya estaría mal
primero
porque la X
ya se ha transformado en X
pero es que al final
además
lo que nos estamos encontrando
es que no sigue
el orden de transformación
la transformación
debería ser siempre
la misma
o sea
aquí si tienes la B
deberías aquí
transformar otra letra
obviamente
y no debería
no debería
o sea
estás utilizando
un orden totalmente distinto
¿por qué?
porque ya aparece aquí
la X
que es la que estaría aquí
o sea
que deberías tener
por ejemplo
aquí
pues podrías poner
la otra letra
por ejemplo
la O
y la X
que transforma la X
debería estar al final
¿vale?
no puede ya estar
en otra letra
y cambiarle totalmente
el orden
porque el orden
tiene que mantenerse
el mismo
no puedes hacer
las transformaciones
de forma desordenada
eso sería el tema
la transformación
se tiene que quedar
exactamente
en el mismo orden
vale
vamos con el
con el ejercicio
de React
¿vale?
venga
vamos con
con esto
vamos a poner aquí
si guardo
el fichero
ah
tengo que poner
punto test
aquí
React
punto test
vamos a intentar
una cosa
no sé si va a salir
así que
les pido por favor
que tengan paciencia
y que no se me vuelvan
locos
vamos a intentar
hacer una pequeña
aplicación de React
sin levantar el navegador
y la vamos a hacer
y la vamos a probar
todo
todo
programando
¿vale?
así que
por favor
tengan paciencia
que luego si no
si algo no funciona
seguro que
os volvéis
y vais a estar ahí
no es que no sé qué
no sé cuánto
bueno
¿qué vamos a hacer?
bueno primero necesitamos
instalar
vamos a instalar
React
y React DOM
¿vale?
con versión exacta
ahora vamos a necesitar
instalar también
de
Bit
el plugin de React
para la configuración de Bit
para que podamos compilar React
y también vamos a instalar
¿qué necesitamos instalar?
Testing Library
de React
y vamos a instalar también
Happy DOM
y ahora te explicaré por qué
necesitamos esto
vamos a ponerlo en modo desarrollo
vale
esto tarda más
porque
¡ay!
ah sí vale
lo he puesto bien
digo ostras que lo he puesto mal
vale
vamos aquí
y vamos a crear
un
bit.config.js
y aquí
en la configuración
de bit
vamos a decirle que
vamos a definir la configuración
define
config
from bit
vamos a
importar
React
from
bit
plugin React
y ahora lo que necesitamos
es exportar
por defecto
el define
config
esto ahora estamos
básicamente
configurando
bit
para que soporte
React
porque si no
no soporta
por sí solo
aquí esto hay que ejecutarlo
y los test
le decimos que
el entorno en el que lo queremos ejecutar
va a ser
Happy DOM
porque necesitamos que React
en este caso se ejecute
con Happy DOM
porque vamos a emular
un DOM
o sea un navegador
para poder
también tener los clics
del usuario
que pueda hacer clic
y todo esto
así que vamos a hacer
lo de Happy DOM
lo hacemos así
esto de test
esto sería
la config
de vtest
vale
esta es la config
de vtest
vale
ya tenemos esto
esto nos está petando todavía
voy a levantar otra vez los test
para que pille la nueva configuración
ya nos está fallando uno
porque nos dicen
no encuentra React
no sé qué
no sé cuánto
lo que nos está diciendo
es que no tenemos ningún test
de React
y tenemos que empezar
a ponerlos
así que vamos a darle
cañita
vamos a empezar con estos
¿qué tenemos que hacer primero?
bueno un describe
el describe
mira ya me ha importado ahí
el describe
vamos a hacer una calculadora
calculator
y aquí
si guardamos los cambios
sigue petando
porque no encuentra ningún test
ves aquí ya te dice
should be able to add
no
esto
vamos a empezar
bien
vamos a poner esto
guardamos los cambios
ponemos aquí el it
ya lo tenemos en verde
pues vamos a empezar
a hacer la calculadora
desde cero con esto
soy más de happy
happy dome
es como un chrome headless
no exactamente
es como un emulador
es como que emula
que hay un navegador
y como lo hace
parcheando todas las APIs
de la web
básicamente
¿vale?
eso es lo que hace
si queréis saber más
de happy dome
lo tenéis aquí
es una alternativa
a js dome
y es como una implementación
de todas las APIs
que habría en el navegador
pero emulándolo
sin necesidad
de levantar un navegador
esto lo que hace
es que sea bastante
más rápido
y es bastante mejor
que js dome
porque js dome
es bastante lento
happy dome
va bastante mejor
que js dome
y además tiene
más
mejor emulados
muchas de las APIs
que hay
por ejemplo
pues temas de cripto
y cosas así
¿vale?
venga
pues vamos
por faena
¿qué es lo primero
que tendría que hacer
en nuestra calculadora?
bueno
lo primero que tendríamos
que hacer
es renderizarla
en el render
lo vamos a hacer
con
texting library
react
no voy a entrar
en detalle
de texting library
react
porque no me daría
la vida
y podría estar
aquí 8 horas
hablando de
react-testing library
pero react-testing library
es una biblioteca
que es de
kensydots
justamente
que te permite
testear muy fácilmente
tus componentes
de react
y lo que puedes hacer
es renderizarlos
buscar elementos
dentro
buscarlos por texto
y todo esto
tienes una API
completa
que lo que permite
es ver
el elemento renderizado
sin necesidad
de levantar
un navegador
pues bueno
vamos a utilizar
esta librería
esta biblioteca
y vamos a ver
un poco
cómo va funcionando
así que
si no la conoces
no te preocupes
porque la API
es muy clara
por ejemplo
aquí necesitamos
el render
de texting library
react
y le vamos a pasar
nuestro componente
que es calculator
guardamos los cambios
y obviamente
esto me peta
¿vale?
¿qué tenemos que hacer
primero?
pues que
bueno aquí tendríamos
que hacer
calculator
should be rendered
o should render
¿no?
debería renderizar
obviamente
no renderiza
porque no está definido
pues ¿qué tenemos que hacer?
ta ta ta
calculator
vamos a definirlo
guardamos los cambios
ya lo tenemos en verde
ahora podríamos decir
que
should render title correctly
queremos que renderice
realmente el título
vamos a hacer lo mismo
¿no?
podríamos esto
hacerlo de diferentes formas
primero renderizarlo
y luego
podríamos utilizar
un objeto especial
que tiene react
still library
que se llama
screen
que sería como
la pantalla
y en la pantalla
podríamos decir
de la pantalla
recupérame
el texto
el get by text
y le diríamos aquí
calculator
este screen
lo tenemos que importar
de aquí
¿vale?
guardamos los cambios
y ahora me peta
¿no?
me dice
no he sido capaz
de encontrar el elemento
con el texto calculator
esto puede ser
porque el texto
está roto
en diferentes elementos
o en este caso
porque la función
que hay machea
no está
hemos ignorado comentarios
script y style
y te pone además
lo que ha renderizado
o sea esto es lo que
habría renderizado
nuestra aplicación
¿ok?
dice te falta el expect
en realidad no me falta el expect
porque como podemos ver
me ha petado el test
¿por qué?
porque en este caso
lo único que quiero
justamente
es
buscar el elemento
eso es lo que quiero
estoy buscando el elemento
simplemente
y como no encuentra
ni siquiera el elemento
pues ya está petando
ya está
¿ok?
así que lo primero
que deberíamos ver
es si puedo
si puedo realmente
encontrar el texto
del calculator
y como podemos ver
no
porque lo que está
renderizando
lo tenemos justamente aquí
así que
lo que vamos a hacer aquí
es screen by
get by text
lo primero que vamos a hacer
es que esto
que renderizar
se estaba renderizando
pero como podemos ver
aunque el render
funcionaba
porque sí que renderiza
pero es que no renderiza nada
que no renderice nada
no significa que no renderice
simplemente es que no renderiza nada
así que vamos a decirle
que aquí vamos a hacer
un return
del h1
calculator
guardamos los cambios
y ahora
ahora
fíjate lo que está pasando
está pasando algo
un poco raro
y es que tenemos
dos calculators
que ha pasado aquí
y de hecho el test
me lo está diciendo
dice el test
dice
y no sé qué
dice
hemos encontrado
múltiples elementos
con el texto calculator
esto pasa
porque cada vez
que tú le das al render
está renderizando
en el body
exactamente
el mismo componente
y por lo tanto
tenemos dos veces
la calculadora
una aquí
y otra aquí
así que tenemos
que limpiar
hacer que limpie
la pantalla
cada vez que queramos
hacer algo
así que en el testing library
tenemos un método
que es clean up
vamos a hacer aquí
que después de cada uno
pues que lo vaya a limpiar
hacemos un clean up
guardamos los cambios
y ahora sí
ya tenemos nuestro primer test
que ha pasado
¿qué es lo que necesitamos
en una calculadora?
realmente
como podemos ver
en este caso
ni siquiera he puesto un expect
¿por qué?
porque es que esto
ya está haciendo
la información que necesitamos
o sea necesitamos
que encuentre de la pantalla
el texto calculator
si no lo encuentra
esto ya hace un
da un throw
y ya tenemos el error
del test
¿vale?
o sea estamos haciendo
los test mínimos
para que realmente
sean útiles
no hace falta
que hagamos un expect
si realmente el test
está petando
y justamente esto
está pensado
para que haga eso
para que lo uses
en los test
y ya directamente
te pete
¿vale?
también podríamos
sí
podrías comprobar
que te renderiza
el h1 también
podríamos también
comprobar
que no está renderizando
el h1
depende
esto podría depender
un poco
o sea por ejemplo
si es importante
que quiero que me renderice
el h1
podríamos mirar
si realmente es un h1
qué elemento es
y todo esto
si no es importante
es más interesante
asegurarse que el texto
es lo que tenemos
porque al final
esto podría pasar
a un h2
podría pasar
a lo que sea
¿vale?
así que tenerlo en cuenta
que al final
eso depende un poco
de lo que queramos
lo que queramos hacer
¿vale?
vale
entonces
vamos a poner otro
porque lo más interesante
serían los números
vamos a hacer
que nos detecte
si tenemos números
si no tenemos números
y todo esto
vamos a hacer
shoot
render
numbers
y aquí lo mismo
podríamos poner
si son botones
y tal
pero ahora mismo
no es tan importante
si son botones
y luego
cuando testeemos
la funcionalidad
de la calculadora
entonces nos preocuparemos
de eso
aquí podríamos tener
otra vez
el render calculator
calculator
y podríamos tener
bueno
podríamos hacer esto
esto sería una forma
de hacerlo
¿no?
3, 4, 5
obviamente esto va a petar
o podríamos decir
¿cuáles son los números
que necesitamos?
tenemos el 0
1, 2, 3, 4, 5, 6, 7, 8
y 9
¿no?
y esto
esto mismo
en lugar de hacerlo así
lo podríais hacer
con un loop
y de cada número
pues podríais
recuperar
getByText
esto así
no hace falta hacer
esto de tu string
esto lo podéis dejar así
y esto debería petar igual
¿no?
y esto lo que está haciendo
es buscar
dice
no he encontrado el elemento
con el texto 0
vale
pues nada
ya está
vamos a encontrar
el texto 0
este numbers
parece interesante
así que lo voy a sacar fuera
más adelante veremos
qué hacemos con él
pero obviamente
necesitamos estos números
tanto en el test
como en nuestro componente
para renderizar los números
así que vamos a renderizar
aquí los números
con el calculator este
lo ponemos por aquí
vamos a poner
para poder renderizar
más
vamos a poner ya el div
y aquí
vamos a poner un numbers map
y en lugar de poner un botón
porque en realidad
el botón
no lo necesitamos ahora mismo
vamos a poner esto
a ver
a este
este
y este
vale
nos falta la key
vamos a utilizar el number
y ya lo tendríamos
ya con esto estamos renderizando
todos los números
obviamente no son botones
pero bueno
los test todavía no nos han dirigido
a ello
¿qué más podríamos hacer?
a ver
si buscamos
si miramos la calculadora
podemos ver que los números
están como en diferentes filas
está la fila esta
la de abajo del todo
segunda fila
tres, cuatro
vamos
no vamos a hacer
la misma calculadora
porque no me da la vida
pero vamos a hacer
que tenga cuatro filas
y para hacer que tenga cuatro filas
para ver la UI
también lo podríamos hacer
un poco con los test
para asegurarnos
que tenemos filas
y que realmente
las estamos mostrando
que sean de cuatro filas
eso lo podemos hacer
bastante fácil
y lo podemos hacer aquí
aunque visualmente
no estemos viendo la calculadora
así que podríamos hacer
it should render
for rows
por ejemplo
o sea cuatro filas
y esto también
lo podríamos hacer aquí
vamos a hacer un render
el render de la calculadora
¿vale?
y
joder
es que ya me lo está diciendo esto
no está mal
lo que podríamos hacer
a ver
vamos a hacerlo de otra forma
hacemos el rows
screen
punto
y vamos a recuperar
todos los elementos
get all
por el roll
de row
¿vale?
una cosa muy interesante
en React Steel Library
es que
puedes recuperar elementos
por texto
puedes recuperarlos
por selector
lo puedes hacer
pero lo más ideal
es que lo hagas primero
por texto
por temas de accesibilidad
como por ejemplo
etiquetas
en este caso
por su roll
en este caso
estamos utilizando ese roll
luego veremos otro
por ejemplo
el del input text
lo podríamos hacer
por su roll
en lugar de hacerlo
por el selector
¿por qué?
porque los selectores
pueden ser
que sea más fácil
que cambie
por eso os comentaba
antes
el h1
es importante
realmente
que esté en el test
depende
si es básico
que esté el h1
pues sí
si da igual
la etiqueta html
pues no
no es tan importante
así que depende
de esa importancia
que vais a mirar
una cosa u otra
en este caso
con el roll
lo podríamos hacer
y de hecho
lo vamos a hacer ahora
y lo que tenemos que mirar
es que esperamos
que rows
tenga un length
de 4
¿vale?
y este expect
lo vamos a importar aquí
y debería petarnos
¿vale?
y ya nos está petando
fijaos que ya
tenemos renderizado
todos los números
pero obviamente
no está haciendo
el tema de los rows
porque todavía
no lo he hecho
así que lo vamos a hacer
ahora en un momentito
a ver que os voy a leer
antes de que siga
test
pensé que eso ya nos hacía más
ya te digo
o sea
pues aquí
te sorprendería
Gonci
porque hay unos cuantos
que ya estaban ahí
que los test
no sirve para nada
no sirve para nada
¿sería mucho mejor
usar un before all?
no
porque el cleanup
no sería antes de todos
en realidad
¿cuándo se hace la limpieza?
se hace la limpieza
justo después del test
no antes de todos
los test
porque si no
al principio
iría muy bien
pero luego
se ejecutan test
y ya entonces
ya no hacen la limpieza
entonces ya estaría roto
y lo mismo pasaría
si haces un before all
o un after all
los dos estarían mal
un before each
funcionaría
pero estarías haciendo
un cleanup
innecesariamente
o sea que sería un poco
de esa forma
venga
vamos a continuar
va
vamos a continuar
que guapo
gracias hombre
subnova
tú también eres muy guapo
no sé si me lo estaba diciendo a mí
vale
entonces
tenemos el tema de los rows
¿cómo vamos a hacer esto?
en el numbers este
que hemos hecho aquí
en lugar de utilizar
los numbers
de esta forma
lo vamos a
vamos a poner aquí
un rows
y ¿qué vamos a hacer?
vamos a tener
por ejemplo
arriba
vamos a tener
7
creo que sí
7, 8, 9
lo de arriba
vale
7, 8, 9
es que depende de la calculadora
no sé por qué me suena
que sale de otra forma
el pan numérico
y un 2, 3
vale
vamos a tener un array
de arrays
en el rows
lo que vamos a hacer
en lugar de renderizar
los numbers
vamos a
envolver esto
con
un div
de hecho
vamos a poner aquí
un section
section
para que no sea tan
dividities
los numbers
los vamos a poner
aquí dentro
vale
obviamente esto sigue petando
porque ahora tenemos
que dibujar los rows
vamos a poner
que en lugar de numbers
esto sea rows
entonces vamos a mapear
y aquí vamos a tener
un row
dentro del row
vamos a
pintar
un div
con el roll
de row
vale
esto lo cerramos aquí
y dentro
es que vamos a tener
de cada row
vamos a papear
los números
fijaos que si yo hago esto
que no está mal
o sea no está mal
tiene bichillos
porque no
no está terminado todavía
esto
podría hacer pasar
que pasen los tests nuevos
pero reventarían
los tests que teníamos antes
vale
así que tened en cuenta esto
por ejemplo
vamos a poner esto
y vamos a poner aquí
el index
vamos a utilizar el index
porque en este caso
no pasa nada
que utilicemos el index
entonces fijaos aquí
que me están pasando
ah
spec is not a function
espérate
que no he importado el spec
antes
así está aquí
ah
es que es este
no sé por qué me ha importado
el que no es
vale
pues esto podría hacer
to half length
la madre que me parió
no tiene un to half length esto
o sea que yo
he visto que ha petado esto
pero no he visto el error
to be
vamos a poner esto
yo pensaba que sí que tenía un
to be
ah
expected 3
to be 4
vale
ah
porque es que me falta aquí
el último row
que es el 0
ves
mira como era importante eso
vale
entonces me está pasando
el test
que hemos hecho de los rows
pero fijaos que me está petando
el de los números
porque hemos hecho una regresión
no
ahora no estoy enseñando
los números
y obviamente es importante
que enseñemos los números
así que vamos a poner aquí
por cada row
vamos a mapear los números
que justamente lo teníamos antes
le vamos a poner aquí el number
y en la key
vamos a utilizar el number también
luego haremos que sean botones
ya veremos como lo hacemos
pero es que ahora mismo
no es interesante
guardamos los cambios
ya tenemos los test
que están pasando todos
vale
pues seguimos
seguimos un poco
en esta línea
¿no?
de otra vez
vamos a hacer esto
podríamos
lo mismo
con las operaciones
vamos a hacer
shoot
render
operations
para tener las operaciones
que queremos hacer
renderizamos la calculadora
vale
y aquí
¿qué queremos tener?
vamos a tener
todas las operaciones aquí
const operations
y ¿qué tenemos?
la suma
vale
suma, resta, multiplicación
y barra
hay mejores símbolos
para hacer esto
pero como lo vamos a hacer rápido
y lo único que queremos hacerlo
con tdd
vamos a hacerlo así
y luego ya veremos
cómo lo hacemos
y lo mismo
aquí pues
operations for each
por cada operación
vamos a recuperar
del screen
el texto de la operación
porque queremos que el botón
o bueno
como se muestra
que esté así
y ya está
obviamente al guardar esto
nos peta
porque no está encontrando
las operaciones
pues nada
otra vez
como podéis ver
estamos construyendo
un frontend
con tdd
y luego
ahora vamos a hacer
también el tema
de los eventos
del usuario
también podemos hacer
que tenga eventos
el usuario
lo vamos a poner
debajo del
fuera del grid
no sé cómo quedará esto
bueno lo vamos a hacer
dentro va
no sé muy bien
cómo quedará esto
pero ya no
luego veremos
cómo ha quedado
¿vale?
operation
y aquí el span
key operation
por ahora lo hacemos así
luego ya veremos
cómo lo hacemos
con botones
por ahora
nos interesa
que vayan pasando
los tests
uno detrás del otro
ahora que tenemos
las operaciones
a ver
nos faltaría
el igual
que ese es bastante importante
should render
equal
equal
sin
¿vale?
este debería ser
un momento
así que renderizamos esto
de nuevo
sé que puede parecer
un poco rollo
pero a ver
si queréis hacer tdd
pues esto es lo que hay
hay que darle cañita
así
¿vale?
tenemos aquí el igual
y aquí lo mismo
pues vamos a poner aquí
un span
vamos a ponerle aquí el igual
bueno queda un poco raro
aquí poner el igual aquí
equal sign
vamos a ponerlo
de una constante
equal sign
y hacemos este igual
¿vale?
nos pasa el test
y ahora vamos a empezar
a hacer ya cosas más interesantes
por ejemplo
vamos a tener que mostrar
un input
así que
¿por qué?
porque en el input
es donde vamos a mostrar
al usuario la información
should render an input
primero hacemos que se renderice
¿vale?
render calculator
screen
aquí hay diferentes formas
una podría ser
si sabéis que tenéis un input
solo
podríais hacer un get by role
y el role del input
por defecto es textbox
si sabéis que tenéis otro
no sé
que por ejemplo
hay un montón de inputs
podríais ponerle
un data attribute
en el caso de que no lo veáis muy claro
o podríais buscar un elemento
padre
por ejemplo el formulario
y a partir de ahí
utilizar el name
en lugar del textbox
podríais utilizar un montón de formas
tenéis un montón de métodos
de hecho lo podéis ver aquí
a ver si sale
get by
no me aparecen
a ver
punto
no me sale
screen
punto
es que me está diciendo
que esto está mal
pero es que no me sale
autocomplete
bueno
no me sale autocomplete
no sé por qué
pero no me sale autocomplete
y el screen está aquí
me lo está pillando
bueno
total
que tienes
get by role
get by name
get by
data test
get by
un montón de cosas
aquí tendríamos
que nos está fallando otra vez
one more time
vale
ahora
vamos a poner el input
lo vamos a poner arriba
veis que si ponemos el input
ya lo pilla
porque por defecto
es un textbox
y ahora sí
vamos a hacer algo
vamos a hacer que cada vez
que clique el usuario
se muestre en el input
vale
vamos a poner show user input
after clicking a number
render
calculator
screen
bueno
aquí lo que podríamos hacer es
vamos a recuperar el número uno
así que primero en el screen
get by text
el número uno
vamos a utilizar el fire event
y vamos a hacer un clic en el uno
fijaos que es que se lee súper bien
o sea es que estamos simulando
que es un usuario
ahora recuperamos el input
que tenemos en pantalla
y el input
esperamos
mira
esperamos que el input value
el valor que tiene el input
sea de uno
esto significa
que debería estar funcionando
correctamente
cuando el usuario
clica en el uno
en el input está saliendo
pero está petando
esperaba un uno
pero esto está vacío
obviamente no hemos añadido
todavía ninguna lógica
de botones
ni nada
ya vemos aquí
que vamos a necesitar
podríamos hacerlo con el span
y hacer el on click
en el span y tal
obviamente
lo mejor es que pongamos un botón
pues vamos a poner ya el button
y aquí deberíamos poner un on click
en el on click
esto
vamos a necesitar un estado también
así que vamos a poner aquí
un value
set value
y un use state
con un string vacío
el input
va a tener este value
y cuando hacemos un on click
lo que vamos a hacer por ahora
es un set value
de el number
por ahora vamos a hacer esto
vamos a
ah
use state
no lo he importado
importante
import
use state
from react
guardamos los cambios
me ha pasado el test
pero me está dando muchas advertencias
me está dando un montón de mensajes
me está diciendo
que está pasando aquí
vale
me está diciendo
has proveído un value
pero no tienes un on change
esto va a hacer que renderice
un campo que sea solo de lectura
en este caso
vamos a querer que sea solo de lectura
más adelante
si quisiéramos
añadirle la posibilidad
de que el usuario
escriba directamente en input
lo podríamos hacer
por ahora vamos a hacer
que solo lo pueda hacer
por los botones
vale
vamos a poner aquí
el retorno
guardamos los cambios
y ahora se ha quitado esto
lo bueno es que ahora mismo
con esto
ya sabemos
que básicamente
está funcionando
perfectamente
nuestra calculadora
cuando le damos un clic
pero que pasa
si lo llevamos
un nivel más allá
porque bueno
está bien que le demos un clic
a un botón
pero obviamente
tendríamos que darle clic
a diferentes botones
algo
vamos a copiar este test
y
should you see input
after clicking
clicking
several numbers
después de clicar
diferentes números
entonces aquí tenemos el 1
vamos a ponerlo también
con el 2
con el 2
esto debería ser el 2
clicamos el 2
y lo que esperaba
vamos a poner también el 3
para que sea un 2-3
vale
3
el 3
y el 3
y si hacemos esto
esto debería ser un 2-3
y si guardo los cambios
me voy a dar cuenta
que me dice que esperaba
que el 3
que es lo que está mostrando el input
se fuese un 2-3
o sea que esto no está funcionando
este test
me está ayudando a decir
ostras
¿por qué no funciona?
porque en el onclick
de los numbers
estoy haciendo un set value
ahí a fuego
¿vale?
estamos haciendo ahí
un set value
a fuego
estamos siempre sobre escribiendo
lo que deberíamos hacer es
el valor
concatenar
el number
¿vale?
así que hacemos esto
guardamos los cambios
y ahora está funcionando
y voy a aprovechar
que todo lo esté funcionando
para hacer un pequeño refactor
vamos a hacer aquí
un handle
vamos a poner
un
create handle number
donde le pasas el número
y esto devuelve
una función
así esto
lo que tenemos aquí
lo voy a poder sacar aquí
lo saco aquí
¿vale?
y ya lo tenemos
y este create handle number
lo puedo poner aquí
y le vamos a pasar
el number
y así nos queda
un poquito más legible
de hecho esto
que también está aquí
un poco regular
vamos a darle
en diferentes
pa pa pa pa
esto por aquí
esto por acá
por aquí
y por aquí
¿vale?
para que esté un poco más legible
luego esto
de nuevo
lo podríamos refactorizar
pasarlo a componentes
ahora que tengo los text verdes
al menos ya sabemos
que lo que hemos hecho
funciona
obviamente
está muy bien el hecho
de que vamos enseñando
los números
pero no sabemos
si funcionan las operaciones
de hecho ya te digo yo
que no funcionan las operaciones
así que
tenemos que saber
que
it
should
user
should
show
debería mostrar
user input
after clicking
numbers
and
operations
¿vale?
una vez que hacemos números
y operaciones
deberíamos mostrarlo también
mira este
me parece genial
renderizamos la calculadora
le damos al número 1
luego recuperamos
el símbolo de más
que es el que hace la suma
¿vale?
plus
mira
plus 1
podríamos hacer el equal sign
pero yo creo que
es demasiado pronto todavía
o sea lo podemos hacer
en otra operación
eso
en lugar de esperar
que nos indique eso
yo lo que quiero ahora mismo
es que el más
aparezca
¿vale?
no quiero tanto el resultado
que eso lo vamos a hacer después
en otro test
sino que quiero que
las operaciones
del más
cualquiera
aparezcan también
así que
vamos a guardar esto
obviamente
esto peta
porque
11 es lo que me ha salido
en el input
y yo esperaba
1 más 1
para arreglar esto
pues nada
¿qué tenemos que hacer?
tenemos las operaciones
las pasamos a un botón
vamos a tener aquí
el create handle operation
bueno en este caso
tanto el number
como el operation
debería ser lo mismo
o sea
vamos a poner aquí
bueno
no lo voy a poner
lo vamos a refactorizar después
vamos a hacer primero
que pase el test
siempre
es que ¿ves?
¿ves?
es que muy mal midu
muy mal
caca
me he adelantado
vamos a hacer que pase
primero el test
y primero
para que pase el test
pues nada
set value
y aquí tenemos que hacer
operation
no
value
punto concat operation
¿vale?
concatenamos la operación
ahora sí que funciona
ahora es el momento
de refactorizar
para refactorizar
la verdad
es que
tanto el create handle number
como este
hacen exactamente lo mismo
entonces
podríamos
como reutilizar
este
create handle click
esto
vamos a poner aquí
operation
como op
porque puede ser un número
puede ser una operación
este create handle click
lo ponemos aquí
y a este
le pasamos un number
y a este
le vamos a pasar
la operation
¿vale?
le pasamos la operation
guardamos los cambios
siguen funcionando
mis test
pues estoy súper contento
porque significa
que no he roto
absolutamente nada
fijaos una cosa
es que sería muy sencillo
ahora de repente
yo estoy refactorizando
hago esto
y me están petando
todos los test
¡ah!
locura
¿por qué?
pues porque he roto
algo que no debía
haberlo hecho
así que lo mejor
que tenemos en estos casos
es el hecho de la seguridad
que refactorizamos
con una batería de test
que nos va a asegurar
que al menos
lo que hemos seguido haciendo
no lo vamos a romper
ahora
¿qué más tenemos?
bueno
lo de las operaciones
y obviamente ahora
lo que necesitamos
es calcularlo
eso sería lo definitivo
¿vale?
así que vamos a hacer aquí
un
show
calculate
based on user input
and show
the calculation
¿vale?
la calculadora
nos tiene que mostrar
el resultado
así que rendizamos
la calculadora
a ver si esto
tiene sentido
lo que me dice por aquí
recuperamos el número 1
luego el plus
para la suma
luego hacemos clic
otra vez en el 1
luego hacemos clic
en el símbolo de igual
recuperamos el textbox
y debería
1 más 1
debería justamente
mostrar
que es 2
y esto
significaría
que mi calculadora
al menos con las sumas
funciona
luego más adelante
podríamos empezar a ver
si funciona con
con los
las divisiones
con lo que sea
podríamos hacerlo
muy a bajo nivel
de empezar con las sumas
luego las restas
e ir haciendo
pero igual
si encontramos una solución
que funcione con todas
lo podríamos hacer
así que
esto obviamente
si lo guardo
no funciona
el nodo
que le hemos dado
no es un elemento
¿vale?
en este caso
dice
fire event click
equal sign
vale
porque aquí
no está recuperando
bien
el elemento
esto
lo tenemos que recuperar
bien
porque no
no lo ha recuperado
bien
by text
equal sign
está utilizando
el equal sign
directamente aquí
no está bien
este sería el elemento
perdón
que me he ido
para arriba
este debería ser
el elemento
¿vale?
lo guardamos
y ahora sí
que me dice
esperaba que
1 más 1
fuese 2
o sea
que no está
haciendo bien
el cálculo
vamos a nuestro
equal sign
button
button
vamos a hacer
un onclick
y aquí
a ver
aquí hay
bastante polémica
pero vamos a hacerlo así
luego
luego lo vamos a iterar
para que lo hagamos
de otra forma
vamos a hacerlo
a saco
¿por qué?
porque quiero que pasen
los tests
es para lo que vivo
entonces
vamos a hacer un set value
y vamos a hacer
un eval
del value
eval
no lo
no lo deberíamos usar
y de hecho
ahora veremos
que no lo vamos a usar
no vamos a usar
ese eval
pero por ahora
vamos a hacerlo así
¿vale?
con esto me está funcionando
pero obviamente
el eval
no es lo que queremos utilizar
en nuestro día a día
existe
una
una librería
que te voy a enseñar
que se llama
math.js
que puedes hacer operaciones
en matemáticas
lo mejor de esta librería
es que podéis hacer
un montón de cosas
y una de ellas
es que tiene un math.evaluate
o sea que vamos a poder utilizar esto
aunque en realidad
y esto te lo dejo
como ejercicio
esta calculadora
utilizando tdd
podrías utilizar
el chaining
que tenéis aquí
¿por qué?
porque conforme vas poniendo números
y tal
tú puedes empezar a hacer
este chaining
y el don
sería darle al igual
pero tú puedes ir haciendo
más 4
multiplicado por 2
podrías empezar a hacer
que funcionase
como esta calculadora
¿vale?
que tú pones 25
por 2
¿vale?
y ves que cuando le das al por
se resetea
esto lo puedes hacer fácilmente
y con tdd
lo puedes conseguir
así que te lo dejo con ejercicio
y con esta librería
lo puedes conseguir bastante fácil
pero hoy no nos da tiempo
así que hacemos un math.evaluate
ahora
y al menos no estaríamos
utilizando eval
y esto internamente
lo que hace es separarlo
para utilizar
no eval
sino sus propios cálculos
vamos a instalar esta librería
en ppm install
install
math.js
y lo mejor de todo
es que ya sabemos
que no funciona
o sea ya ha pasado el test
no es la forma correcta
pero si traemos el evaluate
del math.js
y este evaluate
lo cambio aquí
por este eval
y guardo los cambios
y sigue funcionando
hemos hecho un refactor
cambiando una dependencia
y sabiendo que toda la batería
de test que tenemos
sigue funcionando
otro refactor
obviamente que podríamos hacer
no vamos a querer tener
ahí la calculadora
así que vamos a poner aquí
un calculator
.jsx
¿vale?
y aquí
todo este
que tenemos aquí
todo esto
nos lo vamos a llevar
aquí a la calculadora
vamos a exportar
los numbers
que vamos a necesitar
para nuestros test
las operaciones también
el equal sign up bien
y el componente de calculadora
guardamos los cambios
guardamos aquí los cambios
y aquí
no sé por qué
hostia
esto sigue funcionando
¿qué ha pasado?
ahora se ha vuelto talumba
¿no?
porque
a ver
ah vale
digo
¿cómo puede estar pasando?
a veces le pasa
que se queda
o sea
no está todavía
perfecto
perfecto
pero bueno
¿veis?
calculator is not defined
bueno
vamos a traernos
el calculator
vamos a traernos
las operations
esto lo traemos
del source
calculate
calculator
calculator
vale
vamos a operations
y creo que
el numbers
y el equal sign
vale
y con esto
ya tenemos todos los test
pasando
obviamente
el eval ha sido
aunque no sea objetivo
de clase
que está genial
es más recomendable
usar user event
a ver si es más recomendable
usar user event
antes que el fire event
porque es más real
de hecho es una biblioteca
que tienen
pero no me quería liar
a explicar
todo esto
porque es que si no
no me da la vida
en dos horas
como hemos hecho
tres ejercicios
y tal
pero si tenéis que
simular eventos
de usuario
lo mejor es que utilicéis
esta librería
la de user event
¿vale?
porque esto hace exactamente
lo mismo que haría el usuario
lo otro sería más
como utilizando
los internals
y eso sería como
simulando un usuario
¿vale?
entonces
ahora que tenemos esto
yo creo que una cosa
que podríamos hacer
si os parece
es ver nuestra
calculadora
a ver
ya me imagino
que la calculadora
va a ser horrible
no va a ser muy bonita
no le he puesto ningún estilo
ni nada
pero no me digáis
que no es increíble
y no es súper potente
que hemos hecho con TDD
una calculadora
y que no hemos visto
absolutamente nada
es que no he levantado
el navegador
a mí me parece brutal
la verdad
yo estas cosas
no las veo todos los días
vamos a ver
si realmente funciona
quién sabe
si hemos visto
no va a ser bonita
pero me espero
me espero
que la podamos utilizar
para hacer que
funcione
para poder levantarla
porque es que imagínate
es que no he preparado
absolutamente nada
voy a crear un main JSX
que va a ser el punto de entrada
de nuestra aplicación
voy a importar
React
bueno no sé si necesitamos React
yo creo que no
o sea voy a importar
React DOM
de React DOM
React DOM
barra client
¿vale?
y vamos a importar
la calculadora
calculator
nuestra querida calculadora
¿vale?
y ahora
del React DOM
me voy a traer
el
create root
create root
creamos un root
por cierto
esto es súper importante
que lo sepáis
¿vale?
si creéis que sabéis React
tenéis que ser capaces
de crear una aplicación
desde cero con React
¿eh?
no me digáis que sabéis React
y luego
os dicen
venga
empieza la aplicación de React
y no sabéis
y os quedáis como
no sé cómo se hace
bueno
calculator
que son cuatro líneas
que tampoco es muy difícil
de recordar
y tengo que crear
el index HTML
así que index HTML
creamos esto por aquí
calculator
vamos a poner aquí
calculator
dip id root
que es donde vamos a renderizar
nuestra aplicación
vamos a levantar aquí
nuestra aplicación
con mpn run dev
no
no la vamos a levantar
con mpn run dev
porque no existe
tengo que añadirlo aquí
vamos a poner dev
que hook de bit
y ahora sí
mpn run dev
nos lo pone en la 5173
y no ha funcionado
vamos a ver
qué es lo que no le gusta
qué es lo que no le gusta
espérate
he guardado los cambios
¿no?
de todos los ficheros
main.j
¡ah!
no le gusta
que no he importado el main
mira
es que hay que importar
aquí
type
module
source
source
main
jsx
si no
no funciona
y ahora
nuestra calculadora
nuestra calculadora
2
más
2
igual
4
no está mal
no está mal
3
por 2
6
bueno
yo creo que a partir de aquí
¿ves?
no funciona
ahí no funciona
y ahí habrá que hacer algo
¿ves?
value.com
catisnotafunction
¿por qué no funciona?
hay un test
que falta
pero bueno
no pasa nada
ese test te lo dejo a ti
porque ¿qué pasa
cuando se hace una operación
después de tener un resultado?
puedes añadir un test
vas a ver que te da rojo
porque no funciona
y a partir de ahí
te voy a dejar
que lo veas
no, no, no mintieron
los test
a ver
los test
lo que hemos probado
con test
funciona
lo que hemos probado
con test
funciona
lo que no está funcionando
es algo que justamente
no hemos probado con test
yo no he probado con test
que después de hacer una operación
pueda hacer otra operación
es muy fácil
tengo que añadir un test
y ahí me voy a dar cuenta
que no está funcionando
y ahí me voy a dar cuenta
de cuál es la implementación
que necesito
para hacer que ese caso de uso
pase
entonces
hay que entender
que
es muy sencilla
hay mucha gente que dice
primero
tdb
no significa que vaya a ser infalible
¿vale?
esto es súper importante
no significa que
que nuestro código
nunca vaya a fallar
porque los test al final
somos humanos
y puede ocurrir
que
que no funcione
y luego por otro lado
tenemos el tema
de que
se nos pueden escapar
corner cases
igualmente
y igualmente
yo no he hecho ningún test
para validar esto
así que es normal
que no funcione
es totalmente
válido
o sea
no está mal
en tal
como tal
no está mal
que nosotros
lo que hemos hecho
no funcione
hasta donde hemos probado
podemos ver
que está funcionando
perfectamente
eso es lo que realmente
es interesante
de que
estamos haciéndolo
de forma controlada
y todos los casos de uso
que tenemos controlados
pues los está pasando
sin ningún tipo de problema
eso es lo que realmente
está marcando la diferencia
y si queréis ver realmente
la
lo más importante
de lo que hemos hecho hoy
es esto
es esto
npm run
¿vale?
npm run coverage
y
¿qué hemos hecho esto?
pues hemos hecho
que tenemos
un coverage
del 100%
de nuestras líneas
100%
de todas las posibilidades
del fish bus
del can reconfigure
de nuestro componente
de react
las ramas
las funciones
las líneas
esto
¿sabéis lo que es esto?
esto es un drop de mic
que hemos hecho
dos horas y cuarto
de TDD
desde cero
con pruebas técnicas
o sea
con pruebas técnicas
con casos reales
hemos hecho hasta
TDD
en el frontend
y hemos tenido
un 100% de coverage
que eso no significa
que todo funcione
¿vale?
un 100% de coverage
lo único que significa
es que tenemos test
que están cubriendo
todas las líneas
que tenemos
que muchas veces
eso es mucho más
de lo que tenemos
pero no se me puede decir
que no hemos hecho
un TDD
y que hemos intentado
seguirlo al pie de la línea
¿qué code coverage
aconsejas alcanzar
para una nueva productiva?
a ver
no hay un code coverage
especial
depende de
qué código quieras cubrir
y un montón de cosas
pero
obviamente
cuanto más arriba está
pues más posibilidades
de que te pueda fiar
de los TDD
tener un coverage
del 100%
también os digo
que no significa
que vuestro código
sea infalible
significa
que los TDD que tienes
están revisando
toda la línea de código
que son dos cosas distintas
¿vale?
pero obviamente
si tienes un coverage
de 100%
va a ser mucho mejor
que tener uno
de un 0%
eso seguro
que ya lo digo
¿vale?
así que
bueno amigos
espero que os haya gustado
el stream
este es el tipo de stream
que muchas veces os digo
que
a ver
es que
no me da la vida
es que
no he podido estar
porque es que
si no no me daba tiempo
¿te planteas hacer unitarios
para la lógica pura
como las operaciones
o las cubres
con los tests
del componente?
no sé si es esa
pero
depende
depende
yo la verdad
es que a ver
la
el trofeo este de test
lo más importante
muchas veces
son los end to end
y obviamente
si yo tuviese que
imagínate que no tengo test
yo intentaría
hacer test de integración
antes que test
de unitarios
obviamente
bueno
este es el tipo
de contenido
muchas gracias
a XaviMod
por las 5 subs
EndikaOrbe
Urano
Mark74
Iván Moren
¿sabéis este típico
contenido que decís
¿cuál es el contenido
que necesito
que necesito
para ser senior
para subir de nivel
para que me contraten
y la gente
pues aprende
HTML
CSS
JavaScript
se quedan ahí
oye
este es el tipo
de contenido
que necesitáis saber
el que necesitáis
practicar
el que necesitáis
pelearos
y el que necesitáis
no tener miedo
de aprender
yo creo que hemos
intentado hacer
una introducción
para todos los niveles
que puede ser
que tengáis que repasar
que tengáis que revisar
pero lo bueno
que tiene el TDD
lo bueno que tiene
es que se adapta
a todos los niveles
porque hacéis un test
y los test siempre
van a pasar en rojo
al principio
y a partir de ahí
os podéis pelear
ad infinitum
y lo que os animo
a todos y a todas
es que repaséis
el app ngs
que hicimos
vale
y el que hagamos
el app ngs
tenemos aquí
un montón de retos
igual hiciste los retos
o igual no los hiciste
son retos
que son totalmente gratuitos
te animo
a que los utilices
para que hagas TDD
oye
que pasaría
si ahora
haciendo estos retos
los haces con TDD
cambiaría realmente
la implementación
que tienes
en lugar de ir directamente
a la solución
hacerlo con TDD
que es lo que ocurriría
sabes
entonces
es muy interesante
porque el TDD
muchas veces
lo que te hace
es encontrar la solución
desde otro
desde otro punto de vista
en lugar de ir directamente
a la solución
estás más pensando
en las posibilidades
qué casos de uso
por dónde me pueden pillar
cómo puedo hacer
que el código
me vaya cubriendo
cada uno de los casos
y vas a ver
que el código
queda mucho
pero mucho más
como modular
y se ve
como más claramente
donde está cada cosa
en lugar de estar todo mezclado
lo hemos visto
con el reto
que hemos hecho
el más difícil
que teníamos
en el Adven.js
y este código
cómo se ven
primero las validaciones
primero lo otro
primero lo otro
y poco a poco
este tipo de
además
muchas veces
me has escrito
con el Adven.js
es que no me funciona
esto
no me funciona
el otro
y estoy seguro
que con TDD
habréis visto
que bueno
que es otro
es otro mundo
así que espero
y deseo
que os haya gustado
el stream
este es el tipo
de stream
que necesitáis
de verdad lo digo
sé que da miedo
el tema de test
sé que a la gente
le da pereza
pero es que esto
es lo que marca
la diferencia
muchas veces
me decís
qué es lo que marca
la diferencia
este es el tipo
de cosas
que marca la diferencia
así que amigos
y amigas
muchas gracias
espero que os haya gustado
que config usas
para ver el void
de una función
sé que es una
de Visual Studio Code
pero no me acuerdo
mañana haré un live
en Instagram
¿vale?
porque mañana
como ya sabéis
es mi último día
de trabajo
y mañana
hasta la próxima
en la próxima
Greta
la próxima