Si hay alguien que aprecie un montón, que siempre está con una sonrisa, es impresionante, Debbie,
porque no importa dónde, cuándo, cómo Debbie sonríe. Es que es increíble, incluso cuando
estuve corriendo con ella en Seattle y yo estaba con el pulmón fuera, yo la veía y estaba ahí
sonriendo, que digo, pero esta mujer no se cansa tampoco y es increíble. Debbie, eres increíble.
¿Qué tal, Debbie?
Sí. Y encima estaba embarazada en este momento, yo estaba corriendo súper, súper light y
digo, venga Miguel, vamos, vamos. Bueno, creo que mejora un poquito Debbie en este tiempo,
he seguido entrenando, porque yo he seguido entrenando con la idea de, si vuelvo a correr
con Debbie, no puede ocurrir lo que me ha ocurrido aquí, que estoy en Seattle arrastrando la
lengua, básicamente. Sí, pero bueno, todo el mundo tiene que empezar, ¿no? Y luego mejora,
ahí está. Es como así. Pues Debbie, te quería invitar porque hay un problema, hay un problema
en el mundo de programación y el desarrollo, y es que todo el mundo dice que es, que no
saben hacer test, que es muy difícil, que no sé qué, tenemos que arreglarlo.
Dice que es difícil cuando es fácil, igual que correr.
Exacto. Hay que ponerse, hay que ponerse, ya está, ¿no? Pues Debbie, te dejo para ver
si me los convences a todos y a todas de que hay que hacer test y que no es tan difícil
como se creen. Vale, perfecto, estoy en ello.
Pues mira, te dejo por aquí, mucha suerte Debbie y muchas gracias por pasarte.
Muchas gracias. Bueno, pues mi opinión, todo el mundo puede escribir test fácilmente
y voy a enseñarte un poquito cómo. Sí, mi nombre es Debbie O'Brien, soy un senior
technical PM at Microsoft. Soy un speaker, teacher, youtuber, contribuyo mucho a Open Source.
Y si me sigues en Twitter, dadzionbajoobrine, vas a verme en Mallorca, donde vivo, normalmente
corriendo y haciendo bici por toda la isla, pero justamente estoy cinco meses embarazada
a ponérmelos. Me han dicho que no puedo, súper montaña, estoy haciendo bici chat en
el garaje. No es tan bonito, pero bueno, volveré. Pero sí, afterport es muy, muy importante.
Bueno, vamos a hablar de Playwright, ¿vale? So Playwright, ¿qué es Playwright? Yo estoy
mirando, tengo el chat abierto, es un poco loco, pero estoy mirando eso. Si conoces Playwright
y te gusta Playwright, pues pon Playwright ahí para que yo sé si me sigues. Si es algo
nuevo, pues vas a aprender y vas a flipar que es Playwright. So Playwright es para end-to-end
testing, para testear las modernas aplicaciones y la buena, me gusta mucho, mucho Playwright
en el canal. Muy bien. Playwright funciona en cualquier browser, so tú puedes testear Firefox,
Chromium, WebKit, da igual en cuál plataforma estás. Si estás en un Windows, puedes testear
en WebKit. So, genial. Hay un API solo y los testes funcionan en completamente isolation.
Y luego son súper rápidos. Tenemos un tooling impresionante que voy a enseñarte mucho de
esto. Y también es multilinguaje. Yo voy a decir que TypeScript es el mejor, JavaScript
también. Pero claro, si tú estás ahí, eres un developer de Python o Java o .NET, también
puedes hacer los testes en estos lenguajes. So es súper, súper guay. Bueno, ¿por qué
Playwright? Es que básicamente cuando vas a tu empresa y te preguntan, o tú dices al jefe,
¿no? Tenemos que ir a usar Playwright y te preguntan, ¿por qué? La única cosa que tienes
que decir es porque Debbie O'Brien ha dicho que tenemos que usarlo. Ya está. No hay más
preguntas. Pero no, en serio. ¿Por qué Playwright? Auto-waites. Tiene retries, tiene iframes,
isolation, paralelismo, sharding. Tenemos VS Code, extension, cogen, locator, picker, UI mode,
HTML reports, trace, you're a get-up action. Facio. Vamos a ir un poco en esto. Primero,
vamos a hablar de auto-waiting. ¿Qué significa auto-waiting? Auto-waiting significa que Playwright
va a esperar para que todo está listo, para que el botón está en la página y está clickable.
Entonces, no tienes que decir, oh, ¿cuánto tiempo necesito programar para que este botón
se va a ser listo para pulsar? Porque hay un montón de JavaScript, ¿no? No tienes que pensar
en esto porque Playwright va a esperar automáticamente sin que tienes que pensar en nada más.
Eso está súper guay. Luego, retry. So, assertions es cuando decimos, you expect que esto es igual a esto
o que esto es visible en la página o es, etc. Pues, Playwright va a retry. So, la primera vez que
hacerlo, no ha ido bien, lo va a hacer retry. No ha ido bien, va a hacer retry. A lo mejor lo ha probado
porque podría pasar cualquier cosa como no estaba listo el iframe o etc. So, estos retries vienen con
los assertions de Playwright. Iframes. Es que encantamos los iframes, ¿no? Pero sí, usamos mucho
iframes hoy en día todavía y también el shadowdown. Y Playwright puede hacer el test con los iframes.
Si tú tienes un iframe, puede ser un YouTube video, puede ser cualquier cosa. Puedes testearlo
sin problemas. No hay nada que tienes que pensar ni añadir para hacerlo. Es que se funciona.
Ya está. Fácil. Test isolation. ¿Qué significa eso? Pues, todos los tests son islados. Entonces,
lo que pasa en un test, se queda en ese test. Y lo que pasa en el otro test, se queda en ese test.
Entonces, no comparten el cookies o el storage de cosas como así. Siempre hay cosas que puedes
hacer para antes de todos los tests. Queremos que se hace esto. Claro que sí. Pero no tienes
que limpiar este test. O cuando un test falla, no tienes que pensar, uh, este se ha hecho fallo
porque el test número 3 ha pasado la información. No. Son islados. Paralelismo. Eso es súper,
súper, súper bien porque significa que los tests empiezan, ¿no? Uno, dos, tres, cuatro,
cinco, seis, siete. Toda la vez. Entonces, termina mucho más rápido en vez de un test y luego otro,
y luego otro. Eso es súper lento. Y eso es gratis. No pagamos nada por tener esto. Se funciona como
así, con paralel. Sharding. Eso es complicado esta palabra. Pero bueno, sharding significa que lanzar tu
test en diferentes máquinas. Entonces, especialmente en continuous integration, tú quieres que tu test
ponen en diferentes máquinas y entonces hace el paralelismo y los test lanzan mucho más rápido a través de
estas impresionantes máquinas. Luego, lo tooling que tenemos es VS Code extension. Super guay. Mira,
son 315,000 bajados todavía. Y entonces, si usas VS Code, la experiencia es súper, súper guay. Si no usas
VS Code, no problema. Todavía hay tiempo para que cambies el VS Code. Pero no. También puedes usar el
terminal. Puedes usar cualquier editor que estás usando. Que no pasa nada. Pero bueno, tenemos mucho
features con el VS Code extension. Tenemos herramientas como Code Gen. Eso significa que,
bueno, tú lo sabes. Los queremos programar, pero no queremos escribir código. Solo queremos cobrar.
Pues esta herramienta es para vosotros. Que básicamente esto se escriba tu código para ti. Y vamos a mirar
un demo de esto luego, pero es súper, súper guay. Luego tenemos el locator picker. Si no sabemos qué
locator es, el elemento en la página. ¿Qué es? ¿Es un list item? ¿Qué es un role? ¿Es un checkbox? ¿Qué es?
Pues lo hacemos ese trabajo para ti. Para que no tienes que pensar. Es que estamos haciendo todo para ti.
Luego UI mode. También voy a enseñarte un demo de UI mode. Es mi favorito. Y es una manera de trabajar
súper, súper, súper, súper guay y súper más divertido para cuando estás trabajando con tus tests.
Luego tenemos HTML reports para que veas, especialmente en CI, qué ha pasado, ¿no?
Si ha hecho, si todos han probado, si hay algo que son flaky, si hay skips, si failed, etc. Y puede ver todo el report de estos.
Y luego trace viewer también. ¿Qué pasa? A vez en cuando lo que pasa en mi máquina. Funciona mi máquina. Todo funciona en mi máquina. Y lo pongo a CI y luego no funciona. Y digo, ¿por qué? Pues tenemos un trace viewer para que puedas hacer debugging y ver todo lo que ha pasado en tu test en el CI. Y tú puedes ver qué es el causa, qué es el problema.
Y también GitHub Actions. Super guay. Puedes usar cualquier CI provider, por supuesto, pero mi favorito es GitHub. Y también le damos el GitHub Actions.
No tienes que ni saber cómo escribir en GitHub Actions porque le damos todo. Entonces, la única cosa que tienes que hacer es pon tu test en tu repo, haces push y van. Los tests funcionan en GitHub. Es impresionante.
Vale, vamos a hablar de end-to-end testing. ¿Qué es end-to-end testing? Pues cuando hablamos end-to-end testing significa que queremos probar lo que está haciendo el usuario de principio al final.
So, un, por ejemplo, si estás comprando un billete, pues qué tiene que hacer para comprar el billete y todo el proceso. Y es muy importante porque antes pensamos, hay que escribir un test y gastamos todo el tiempo.
Un test, un test, un test, un test. ¿Por qué? Porque antiguamente los end-to-end testings eran lento, costoso y ahora no es el paso.
Y realmente lo que tenemos que estar haciendo es testeando lo que hace el usuario. Es muy importante. ¿Cuántas veces has usado una página y no funciona? Algo no funciona y estás convicada en la... Es que es esto. Tenemos que probar lo que hace el usuario.
Y end-to-end testing es lo que va a hacer tu vida mucho más fácil.
So, vamos a mirar un poquito del tema de CodeGen. CodeGen es nuestro generador de tests. Entonces, para la gente que dice, tests son difícil, mira esto porque no tienes que ni hacer nada.
So, básicamente, yo tengo el BIOS Code abierto y lo tengo la BIOS Code extension instalado, pero tú puedes usar el término. Si no quieres usar BIOS Code, no pasa nada.
Y lo que voy a hacer es enseñarte en, yo creo que en dos minutos, escribir un test. Vamos a ver. Vamos a pulsar el botón Record New.
Ahí en la izquierda. Y me da una página, ya, con todo empezado. Y un browser window. Vamos a testear esta web que es el Contoso Traders.
Aquí es la web. Fantástico. Y ahora lo que vamos a ver en BIOS Code es ahí, lo await page go to, la página donde queremos ir. Fantástico.
Y no ha escrito código y mira. Venga, ¿qué vamos a hacer? Vamos a buscar un Xbox, ¿no? Vamos a comprar un console o algo.
So, buscamos el Xbox y a mí me gusta esto en el medio. Está muy chulo. Voy a comprar esto. Necesito dos porque tengo un amigo y quiero jugar con él.
Voy a añadir la bolsa. Hostia, mira, está aquí. Voy a abrirlo y aquí en la bolsa hay los dos Xbox. Es fantástico, pero no tengo dinero,
solo voy a quitarlo del bolsa, del carrito. Y mi carrito ya está vacío. Entonces, genial. Aquí es el test, ¿vale?
Mira todo el código que ha escrito el CodeGen. Yo no he hecho nada. Solo clic como el usuario y me ha escrito todo.
Puede cancelar el generator y puede clic en Show Trace Viewer y puede lanzar este test.
Entonces, lo lanza esto y aquí mismo, ¡pam! Ahora es todo el trace de mi test. Todo lo que he hecho, cada acción.
Lo que ha pasado en cada momento. Y tengo todo esto grabado para que pueda revisar.
Claro, tengo que escribir una assertion porque no hemos testeado nada, ¿vale?
Entonces, voy a expectar que el Xbox Wireless Controller está en la bolsa.
Antes, de hecho, remove. ¿Qué va a pasar? Pues, está en rojo. Fantástico, porque cuando yo le clique remove,
no debería tener que comprar nada. Voy a moverlo hasta arriba, voy a lanzar el test otra vez y va a... y funciona. Perfecto.
Y luego abajo, cuando quita el botón remove, puede poner otra assertion para decir que el Xbox no está visible,
no está en la página, no está en el carrito, no está en la bolsa.
Y voy a poner play en el test otra vez y claro que se va a funcionar porque soy un crack y escribo test impresionantes.
Y entonces, yo estoy feliz y puedo ir a casa en el viernes feliz y sabiendo que mi código no va a romper producción.
Entonces, eso es coaching. Es súper, súper sencillo, es súper guay.
Y como puedes ver, es muy fácil a empezar a escribir los test. Tienes que escribir tú los assertions, ¿vale?
So, te hace grabar todas las acciones, pero luego tú tienes que escribir los assertions.
Y si vemos el código aquí, lo ves que tenemos get by role, get by role button, por ejemplo, get by label card.
So, usamos user-facing attributes. Eso es muy importante porque también estamos testeando accesibilidad.
Y si has venido de unit testing con testing library, por ejemplo, vas a mirar esto y vas a sentir muy similar.
Lo que usamos, basado en testing libraries, en Kent C. Dodds, en los user-facing attributes.
Y hemos cogido eso, trabajado con Kent y hemos puesto todo esto similar.
So, súper guay.
Vale, esto es coaching.
Yo he visto a una persona preguntando por qué light mode, solo para escucharla.
Yo no puedo código como así en la vida normal.
Yo estoy dark mode, siempre.
Pero para vosotros, para la charla, está en light mode.
Vale, vamos a mirar UI mode.
Vale, UI mode es mi favorito.
Es súper, súper guay.
Y esto es, ¿qué ha pasado?
La gente está escribiendo su test y luego han dicho al equipo de Playwright,
mira, necesitamos watch mode.
Necesitamos que cuando cambiamos algo, que están mirando, que no tenemos que poner play.
Porque, claro, haciendo click en play cada vez es trabajo, ¿no?
Play, play, play.
No queremos.
Entonces, creen watch mode.
Entonces, lo que hemos hecho es cogido el trace viewer y hemos hecho un wrapper y es UI mode.
El UI mode usa el trace viewer, pero luego también puedes watch los test.
So, súper guay.
Y lo que yo te voy a enseñar ahora, si estás en casa, si estás usando Playwright, va a decir,
¿por qué el mío no es como lo de Debbie?
Porque yo estoy usando la próxima que va a ser en el release 1.38 en, no sé si mañana o el día siguiente,
pero es la nueva, nueva.
So, hay un par de cambios.
So, súper chulo.
Vamos a ver el demo.
So, esto es UI mode, ¿vale?
Entonces, a la izquierda tenemos el panel con todos los tests que tenemos en nuestro repo.
Y en el medio tenemos, arriba es el timeline.
En el medio es el DOM snapshot, donde vamos a ver las imágenes.
Los actions van a estar en el sitio donde está.
No hay nadie, está todo blanco.
Todos los actions van a estar aquí.
Y luego abajo tenemos el locator, para buscar un locator, el source code.
Tenemos el call, el log, los errors, los consult, los network requests y attachments,
si haces visual regression.
Vale, vamos a ver qué podemos hacer con UI mode.
Preparate.
Está súper guay.
Entonces, ponemos Play aquí.
Y aquí tenemos, pues, todo nuestro test lanzado.
Súper simple este test.
El get started test y lo ves y podemos mirar.
Mira, el get started button, hemos clickeado esto y hemos ido a la página de instalación.
Y ves el código, está highlighted justo debajo.
Mientras estamos clickeando en las acciones.
Vamos a lanzar el test que hemos creado con Code Jam.
Vale, perfecto.
Aquí tenemos el test.
Yo he hecho un poquito de cambio aquí porque he hecho el programador.
Se estaba usando un poquito.
So, aquí tenemos el test, ¿vale?
Cada cosa, hemos buscado el Xbox.
Luego hemos puesto el aquí.
Lo ves aquí mucho mejor, ¿vale?
So, tenemos el Xbox.
Y lo ves el cerquilito donde estamos clickeando.
Eso es donde Playwright está clickeando.
Y luego hemos puesto dos en el carrito.
Perfecto.
Y luego, ¿qué ha pasado?
Pues, mira, yo tengo un error.
He clickeado en Add to Bike.
Pero, ¿qué ha pasado?
¿Vale?
Está.
El Bike tiene alguno.
Pero luego hay un timeout.
Hay un timeout.
Y el código me dice en línea 12 await page getbylabelback.click.
Y está esperando por el getbylabelback.
Y digo, ¿qué pasa aquí?
Entonces, tengo un problema con el test.
¿Qué hago?
Pues, uff.
Entonces, lo dejo de escribir test porque el test no funciona.
Lo sube el código y no.
Hay que siempre arreglar los test.
Cuando ves algo en rojo, está bien.
Entonces, lo puedo clickear en todo para mirar qué está pasando aquí.
Y cuando no sabes cómo arreglarlo, lo miras el error.
Vale.
Esto no me ayuda porque es waiting for getbylabelback.
¿Cómo puedo arreglar esto?
El source code dice está en línea 12.
Vale.
OK.
Pues, lo que puedo hacer es mirar el código, ¿no?
Porque a lo mejor este label, pues, no es bug.
Yo qué sé.
Para mí, yo veo un bug, parece bien.
Antes, ¿qué ha pasado?
Clic en Add to bug.
After.
Lo puedes ver todo.
Before y after, ¿qué ha pasado?
Y podemos intentar entender qué ha pasado.
Aquí el bug tiene el 1.
O sea, el bug está correcto.
Pero no.
El test ha dicho que no.
No se puede click en esta bug.
¿Por qué no se puede click en esta bug?
El timeline, todo funciona tal cual como queremos hasta este momento.
Entonces, vamos a inspectar nuestra icono, el bug.
Y lo que podemos hacer, ¿vale?
Es click en el bug y en un DOM snapshot.
Lo vamos a hacer en pop out para que está en Windows separado.
Vamos a inspectarlo porque es un DOM snapshot, ¿no?
No en imagen.
Tenemos el DevTools y lo podemos mirar, seleccionar esto y mira qué pasa.
Es un button, tiene un class, tiene un type button y tiene un area label cart.
Aquí es nuestro problema, ¿vale?
A mi ojos, yo veo un bug, pero el programador ha decidido que es un cart.
Entonces, en el accessibility tree, el button es cart, area label es cart.
Entonces, pues, para mí es un bug, pero por el código es un cart.
Entonces, sabemos que eso es el problema.
So, es muy bonito de cómo podemos ver esto y arreglarlo.
También tenemos el locator picker, mucho más fácil.
Lo clica aquí y lo clica y me pone get by label cart.
Y ya está.
No tengo que hacer el inspector, no tengo que mirar el accessibility tree.
Solo tengo que usar los herramientas de playwright y clica en locator y bam, ya lo tengo.
Y mira, yo puedo jugar aquí, es un playground.
So, puedo escribir y me pone un highlight del locator que hay.
Entonces, bam, tú lo ves, no hay nada, pero si pongo cart, bueno, si pongo nada,
lo ves que hay muchas cosas porque hay muchos labels y empiezo a escribir cart y lo ves,
que el valor de cart existe.
Y también eso es un locator playground, eso es nuevo en la nueva versión.
Y puedo empezar a escribir, seleccionar cualquier locator haciendo click y jugando live y escribiendo
y viendo qué hay en este DOM snapshot, etc.
So, es súper guay, es súper más fácil en buscar qué elemento en la página,
qué role tiene y dónde está el file.
Y esto tampoco, también en CI, funciona como así.
Entonces, vamos a seleccionar nuestra cart y vamos a copiarlo.
Y vamos a clicar en los ojos esto para watch.
Y luego vamos a VS Code.
Y luego aquí, pues, vamos a pegar, inventar, vamos a poner cart.
Y no tengo que poner play porque he puesto watch mode,
so cuando vuelvo directamente ya está lanzado el test otra vez.
Y entonces empieza y pam, nuestro test está arreglado,
todo está bien y yo puedo ir a casa súper, súper contenta porque todo funciona como debería funcionar.
Y esto es súper guay.
Esto es muy importante, lo puedes ver, que ya Playwright puede click en esta bag
y podemos ver qué hay en la bolsa, los dos consoles, tal cual como querimos.
So, súper guay.
UI mode es súper guay.
Para usar UI mode solo tienes que hacer npx playwright test dash dash UI.
So, cuando la nueva versión sale, vas a tener todo estas tal cual como la ves
y vas a disfrutar jugando con Playwright y cuando tienes el file,
pues, puedes arreglarlo mucho, mucho, mucho más fácil.
Vale, ¿qué más?
Pues, vamos a mirar un poquito a scaling.
Entonces, ¿qué pasa cuando tienes mucho test?
Y tarda un montón.
Y yo, por ejemplo, tengo una página web mío que se llama debi.codes.
Es open source, tú puedes verlo, te puedes clonar, copiar, ver todo lo que quieres.
Y ahí, pues, mi test tardaba en unos 20 y pico minutos, que no está mal,
pero es mi página, súper, súper simple.
Imaginar una empresa que tiene, pues, muchísimo código, muchísimo test.
Y los test tardan los días.
Pues, la gente dice, buf, no voy a más escribir test porque tarda mucho.
Más, lo que podemos hacer es arreglar el fallo con scaling on CI.
Entonces, cuando lanzamos el test con CI, por ejemplo,
yo he lanzado este PR para hacer un update en vídeo y tú ves que esperar 18 minutos.
Es como 18 minutos.
Vale, pues, imagina una hora y media.
Terrible.
Pero lo que podemos hacer con Playwright es sharding.
Y sharding significa que tú pones tu test en diferentes CPUs.
Entonces, en vez de tener, creo que tengo 200 test, pues, lo dividirlo en cuadro.
Voy a usar cuadro máquinas.
Y entonces, la cuadra empieza a la vez, dividido en 200 entre cuadro.
Y mírala el tiempo, 8 minutos.
8 minutos 41 segundos.
Vale, está mucho más de la mitad.
Fantástico.
O sea, imagina si son 3 horas, pues, menos de una hora y media.
Genial.
Hostia, ganamos un montón de tiempo.
Y eso es muy fácil de hacerlo.
Y puedes ver mi repo si quieres verlo.
También está documentado.
Solo tienes que añadir un poquito de código en tu getup action.
Y luego puedes, en tu Playwright config, tienes que añadir otra cosa y ya está.
Simple.
So, mirar en hacer esto.
Y luego, claro, antes lo que ha pasado es tienes un HTML report,
pero ya tienes cuadro de reports, ¿no?
Pero en el último release hemos hecho merge reports.
So, mergeamos estos reports para que tienes un report con todos estos shards junto.
Entonces, puedo ver mi 292 test y puedo ver un report con todo aquí.
Mucho, mucho mejor.
So, esto es sharding.
So, mira eso también.
Entonces, ¿qué más puede decir de Playwright?
Espero que todavía pienses es super guay.
Porque Playwright es open source.
A mí me encanta open source.
Y Playwright es open source y gratis.
Gratis.
Me encanta gratis también.
Es el, yo quiero todo gratis.
Y creo que en España, todos los españoles solo quieren todo gratis.
So, está muy bien.
Entonces, Playwright, sí, es de Microsoft, pero es open source.
Tú lo ves, todos los NPM downloads que tenemos.
Playwright es más o menos tres años por ahí.
Los GitHub stars, que son 50.000 para arriba.
Impresionante.
Si vas a la repo de Microsoft slash Playwright en GitHub,
darnos un star, una estrella en GitHub,
porque, como si yo cobro, si no me das una estrella,
un GitHub star, yo no gano dinero al final del mes
y luego estoy súper pobre.
Encantamos los stars o dar una estrella.
¿Qué más te puedo decir?
Pues, tenemos un programa de ambassadors súper, súper genial
que está creando un contenido súper guay.
Kenzie Dodds, por ejemplo, seguramente lo conoces.
Y mucha más gente.
Y si no tiene inglés bien, no pasa nada,
porque tenemos a Carlos Gauto, que hace muchas cosas en español
y tiene su Twitch y está dando mucho a Charles,
está en Argentina y es fantástico también.
Entonces, mira todo el contenido de Carlos,
si solo hablas español.
Y si no, pues, mira todos los demás también.
Tenemos Discord, que Discord es súper guay.
Tenemos más de 6.000 y pico gente en Discord,
que está impresionante porque solo hemos empezado en diciembre
con Discord.
Y ahí tenemos, pues, mucha gente compartiendo vídeos,
artículos.
Tenemos un canal de ayuda donde la gente está ayudando
entre ellos mismos.
Y también hacemos happy hour,
donde bebemos cervezas, por honor.
No.
Donde hablamos de playwright, por honor.
Y hacemos esto cada, no sé cuándo,
en cada viernes, cada tercer viernes, por ahí.
So, sí, mira nuestro Discord server.
Y básicamente, yo quiero decir,
si estás usando Playwright, muchas gracias.
Y gracias por ser parte de esta comunidad,
porque sin la comunidad, Playwright no es nada.
¿Vale?
Playwright es de Microsoft,
pero Playwright es por la comunidad.
Y sin la comunidad, no hacemos nada.
So, gracias por ser parte de la comunidad.
Y si no eres, ¿por qué no eres?
Y realmente, mi pregunta es para esta gente que no sabes que es Playwright,
que nunca ha hecho test, que piensa que test son difíciles.
¿Has visto esta presentación ahora?
Pues, espero que has cambiado de opinión y eres listo ya para Playwright,
para escribir test y para mejorar tu código.
Yo te cuento una cosa.
Tú lo dices a tu jefe, mira, ya han pasado el escribir test,
ya tenemos todos los test hechos, te van a subir el sueldo.
Y si no, lo dices,
Debbie ha dicho que tengo que comprar más porque he escrito test.
Ya está.
Da mi número el jefe.
Yo lo abro con ellos.
Muchas gracias para escuchar, para tu tiempo,
por el chat, que está fenomenal.
Sois un cracks.
Los docs, Playwright.dev, tenemos Twitter, YouTube y Discord.
Mi página es debi.codes.
Puedes ir ahí y todos mis links están ahí.
Y puedes ver todo lo que tengo yo para compartir.
Puedes escribirme en un email,
debiobryan.microsoft.com
Pero no leo nunca los emails,
pero si quieres escribirlo puedes.
Pero en serio, muchas gracias por tu tiempo
y para estar parte de esta conferencia.
Muchas gracias, Miguel.
Otra vez estar aquí es impresionante.
Eres un crack.
No, gracias a ti.
O sea, Debbie, muchas felicidades porque el trabajo que estás haciendo
como DevRel ahí en, bueno, Senior Program Manager, perdón.
Senior Program Manager, ¿no?
Sí.
Y añadido la palabra Technical.
Senior Technical Program Manager.
Ahora es más largo.
Me encanta.
Senior Technical Program Manager.
Pero desde luego,
es que yo me quedo embobado como lo explicas
y es que me entran unas ganas de empezar a hacer test
que es una cosa que muchas veces pues nos da pereza,
pero es que se ve tan fácil.
Con una experiencia de desarrollo tan increíble
que me encanta.
Así que, Debbie, muchísimas gracias.
Espero y deseo que hayas convencido a alguien ahí fuera.
Yo creo que sí.
Sí, hombre, yo también creo que sí, ¿eh?
Porque es que ese momento en el que enseñas
cómo se hacen solos,
o sea, que necesitas ya que vaya Debbie a tu casa a hacerlos.
Sí, sí, sí.
Es lo que tengo que hacer.
Ay, Debbie, oye, enhorabuena a ti
y a todo el trabajo del equipo que están haciendo Playwright.
Lo estáis haciendo increíble.
Es una herramienta maravillosa
y que ojalá signifique que la gente va a dejar de tener pereza
por hacer test porque se necesita.
Y es guay.
Testing es guay.
Es guay, es que es divertido
porque se hace como más gamificado, ¿no?
El hecho de dónde está el error, lo ves, lo mueves y tal.
Sí.
Es increíble, me encanta.
Debbie, te mando un abrazo enorme.
Que sepas que mientras estabas ahí
se ha puesto tendencia a la MiduConf en el puesto número 3
y yo creo que tú tienes mucho que ver.
Así que increíble.
Eso es súper chulo.
Así que enhorabuena.
Te mando un abrazo enorme, Debbie.
A ver si nos vemos pronto.
Mucha suerte con tu embarazo.
Te va de todo genial.
Gracias.
Tengo ganas de ver ahí a los o las minis, a las minidebis.
Van a salir haciendo test.
Ya te digo, con un Playwright bajo el brazo.
Sí.
Qué bueno.
Bueno, en Playwright tienen dos máscaras.
A ver si te vas a ver uno bueno y uno malo.
Puede ser, puede ser.
No, dos seguro que salen buenos.
Buenos o buenas.
A ver qué sale por ahí.
¿Ya sabes quién va a ser el género?
Sí, son chicos.
¿Son chicos?
Ah, vale.
No voy a saber quién es quién.
Va a ser, madre mía, quién es quién.
Ah, qué bueno.
Bueno, pues nada.
Que vaya genial con tus niños.
Y te mando un abrazo enorme.
Nos vemos pronto.
Gracias por pasarte.
Y por seguir petándola y compartiendo tu conocimiento.
Que eres una crack.
Muchas gracias, Debbie.
Gracias.
Cuídate.
Un abrazo.