Prueba tu interfaz de usuario en el navegador REAL

Hoy estoy emocionado de mostrarte algo en lo que he estado trabajando durante los últimos meses. Pero primero, cubramos lo básico. En estos días, las interfaces de usuario se construyen utilizando componentes. Todos los frameworks modernos proporcionan una forma de hacer desarrollo basado en componentes. Incluso los frameworks de servidor como Ruby on Rails ahora proporcionan una forma de construir y usar componentes. Esto tiene sentido porque el desarrollo basado en componentes aporta muchos beneficios. Puedes trabajar de manera más eficiente porque no todos los elementos de la UI tienen que ser personalizados. Puedes acelerar el desarrollo al paralelizar el trabajo entre personas y equipos. Y las interfaces de usuario se vuelven más duraderas a medida que se dedica más atención a las API de los componentes trabajando en ellos de forma aislada.

A pesar de los esfuerzos de los autores de los frameworks para reducir la barrera de crear grandes interfaces de usuario, aún es difícil realizar pruebas correctamente. Realizar pruebas en una aplicación en ejecución puede ser lento e inestable, y reproducir un error es difícil. La lógica empresarial compleja significa que hay toneladas de escenarios y estados que considerar, los cuales no se pueden probar manualmente. Especialmente cuando tu UI está en constante desarrollo. Las herramientas de prueba existentes también dejan mucho que desear. Si lo piensas, es absurdo cómo el status quo es ejecutar pruebas unitarias con JS DOM, que es un entorno totalmente diferente al que se ejecutará tu interfaz de usuario. O que debas instalar un navegador separado para ejecutar y depurar tus pruebas de interacción.

En caso de que aún no estés familiarizado con Storybook, es una herramienta para construir componentes de UI. Proporciona un entorno aislado para tus componentes, para que puedas centrarte en cómo funcionan y se ven en todos sus estados y variantes. Funciona con todos los principales frameworks frontend. Storybook se construye principalmente para ejecutarse en tu máquina local, junto con el código de tu proyecto, mientras desarrollas o pruebas aplicaciones. Pero también puedes cargar una versión estática para compartirla con colegas o clientes. Storybook se puede ampliar con cientos de complementos, para integrarse con herramientas de diseño como Figma o conectar componentes a una fuente de datos, renderizar componentes como los vería una persona con daltonismo, o generar documentación de componentes. Es la única fuente de verdad para los componentes de UI. Cuando trabajas en Storybook, construirás componentes de forma aislada. Storybook proporciona un lienzo en el que renderizará tus componentes. En un flujo de trabajo típico, ejecutarás tu Storybook junto con tu editor de código.

Storybook se trata de catalogar variantes de componentes y categorizar componentes para formar una biblioteca de componentes organizada y fácilmente buscable. Esto ayudará a todos a encontrar los componentes que necesitan, facilitando la reutilización de lo que ya está disponible.

Storybook es un proyecto de código abierto impulsado por una gran comunidad de colaboradores. Es confiable para miles de equipos de desarrollo en todo el mundo. Se utiliza en empresas como Shopify, GitHub, IBM y la BBC. ¡Incluso está apareciendo cada vez más en los currículums de las personas!

La principal innovación de Storybook es el concepto de Historias. La mayoría de los componentes de la interfaz de usuario tienen más de una variación. Una Historia es un fragmento de código que representa un componente en una de esas variaciones. Piensa en cosas como estados de carga, estados de error y estados funcionales, como un interruptor. Pero también hay casos extremos, como valores extremos, contenido desbordado o datos faltantes. Y finalmente, hay variaciones dependientes del contexto, como si un usuario ha iniciado sesión o no, su idioma, si prefiere un tema oscuro o cuál es su variante asignada en una prueba A-B. Y para empeorar las cosas, también hay innumerables combinaciones posibles, ciertamente no es algo que quieras probar manualmente.

Las historias se definen utilizando el formato de historia de componentes, o CSF por sus siglas en inglés. Es una especificación abierta compatible no solo con Storybook, sino también con muchas otras herramientas. Esto significa que puedes escribir historias una vez y reutilizarlas en varios lugares. No hay dependencia de API, porque simplemente estás escribiendo JavaScript básico. Si quieres, puedes usar historias con Playwright o Cypress.

Ahora adentrémonos en algo de código. Esto es lo que se ve un archivo de historias simple para un componente de insignia. En la parte superior, importamos el componente y definimos un objeto de metadatos. Este es la exportación predeterminada. Este objeto se puede utilizar para definir cosas como el tipo de datos que necesita este componente, dónde se encuentra en la jerarquía de componentes, especificar argumentos predeterminados y envolver el componente con un proveedor de datos. En este caso, solo necesitamos decirle a Storybook qué componente estamos representando. También estamos especificando una etiqueta predeterminada. El componente de insignia tiene una variante pequeña y una grande, por lo que definimos dos historias, pequeña y grande, que solo difieren en su propiedad de tamaño. Para escribir una historia, realmente solo se necesita un objeto JavaScript básico. Ahora que sabes cómo definir historias, podemos agregar interacciones. A veces, un componente tiene variantes que no se pueden expresar solo pasando argumentos. Tal vez no puedas o no quieras cambiar la API del componente, o el componente está anidado dentro de otro componente, como una página.

Incluso hay un complemento de ESLint para ayudarte a escribir funciones de reproducción sin caer en errores comunes. Además de ejecutar historias interactivas, también estamos trabajando en la interacción de pruebas. En los próximos meses, lanzaremos herramientas para hacer afirmaciones en tus funciones de reproducción. El complemento de Interacciones te permitirá depurar tus pruebas de forma interactiva directamente en tu navegador. Lo genial de usar Testing Library con Storybook es que se ejecuta en tu navegador habitual, lo que significa que puedes utilizar las herramientas de desarrollo que conoces y amas, y no necesitarás instalar ningún software adicional. Utilizando el Ejecutor de Pruebas de Node.js, podrás ejecutar todo el Storybook como un conjunto de pruebas, y cuando algo falle, recibirás una URL con la que podrás reproducir el error.

Ahora veamos cómo funciona esto en la práctica con algo de codificación en vivo. Muy bien, he configurado un componente simple para un formulario de cuenta con un archivo de historias, y lo que quiero hacer ahora es escribir algunas historias para el estado del campo. Así que vamos a hacer eso. Exporta const field, y es solo un objeto simple. Tiene una función de reproducción en ella, que siempre es una función asíncrona. Entonces, lo que queremos hacer aquí es escribir algunas interacciones con el componente en ejecución en Storybook. Para hacer eso, primero necesitamos obtener el elemento del lienzo, para poder apuntar nuestros selectores a ese contenedor. Eso se pasa en el contexto de la historia que recibe la función de reproducción, elemento del lienzo. Y luego podemos usar una utilidad de la biblioteca de pruebas para obtener un selector específico. Importa within de storybook/testing-library. Y ahora const canvas equals within ese elemento del lienzo. Bien, guardemos nuestro archivo y veamos si obtenemos una nueva historia. Entonces, en Storybook, ha aparecido una nueva historia, pero aún no hace nada especial. Muy bien, no hemos hecho nada. Así que sigamos escribiendo algunas interacciones. Para hacer eso, necesitamos user event de la biblioteca de pruebas. Y decimos await user event.type, porque queremos escribir en este campo de entrada y, bueno, ahora necesitamos proporcionar un elemento. Entonces, ¿cómo obtenemos un nuevo elemento? Bueno, para hacer eso, necesitamos crear un nuevo cliente.

Bien, ahora necesitamos proporcionar un elemento. Entonces, ¿cómo obtenemos ese cuadro de entrada? Lo genial es que puedes usar las herramientas de desarrollo regulares de tu navegador aquí para inspeccionar el elemento. Y podemos ver que este campo de entrada tiene un ID de prueba data, que puedo copiar y pegar. Dame eso. Y luego digamos canvas get by test ID, no obtener todos, solo obtener ese, mi ID de prueba, correo electrónico, y por supuesto, proporcionar un valor. Hola. Guardar mi archivo. Y boom, Storybook ha vuelto a renderizar instantáneamente mi componente, ha completado el formulario y también ha listado eso en el panel de interacciones.

Hagamos lo mismo para la contraseña. Contraseña, hola mundo, por supuesto. Guardar mi archivo. Boom. Tenemos dos interacciones aquí. En realidad, podemos pasar el cursor sobre estas cosas, hacer clic en ellas, para ver qué está sucediendo en ese paso en particular. Puedes retroceder y avanzar entre las interacciones. Entonces, veamos qué sucede cuando hago clic en ese botón de crear cuenta. Boom, hay un error, por supuesto. No he completado una dirección de correo electrónico válida y la contraseña no es lo suficientemente larga.

Entonces, escribamos una historia para este estado particular de mi componente. Porque este es un estado totalmente válido que las personas pueden encontrar y queremos escribir una historia para ello. Entonces, export const invalid. Esta es una nueva historia. Voy a tomar una función Play. Y nuevamente, una función Async. Y en lugar de repetirme aquí, simplemente voy a usar la función Play de la historia anterior. Entonces, necesito esperar eso. Build.Play. Y la función Play necesita un contexto de historia. Así que pasaré ese contexto. Guardar mi archivo y debería tener una nueva historia.

Haz clic en él. Boom. Lo mismo. ¿Verdad? La misma historia.

Ahora, vamos a ampliarla. Nuevamente, necesito un lienzo. CanvasElement. Y ahora puedo hacer await. UserEvent.click. Porque quiero hacer clic en ese botón para activar el estado envuelto. Lienzo. Nuevamente, por rol. Rol. Botón. Guardar mi archivo, ver qué sucede. Boom, ocurrió un error. Bueno, encontró varios botones en la página porque, por supuesto, también hay un botón de reinicio aquí. Entonces, necesitamos especificar exactamente cuál queremos. Guardar. Y boom, funciona. Ahora tenemos una historia para este estado envuelto.

Echemos un vistazo más de cerca aquí. Hay este mensaje de error y tiene este tooltip. Ampliemos, ampliemos esta historia en particular para mostrar también el tooltip al pasar el cursor. Podemos hacerlo totalmente usando userEvent. userEvent.hover Y ahora, nuevamente, no sé qué componente, qué historia, qué elemento necesito. Entonces, inspectElement y hay un ID de prueba en él. Cópialo y haz canvas.getByTestID Pásalo, guarda mi archivo y ocurrió un error. Bueno, ¿qué está pasando aquí? Entonces, este es un problema particular al escribir pruebas para elementos interactivos.

Especialmente si tienen un proceso asíncrono allí. En este caso, validación de formulario asíncrona. Entonces, después de hacer clic en el botón, tarda muy poco tiempo en aparecer ese mensaje de error. Entonces, necesito usar una consulta diferente aquí. Y, afortunadamente, Testing Library proporciona un selector diferente para hacer eso. FindByTestID, que es algo asíncrono, así que necesitamos esperarlo. Guarda el archivo y ¡ahora funciona! Entonces, verás que la historia se actualiza y realmente ha abierto ese tooltip, lo que significa que el hover funcionó.

Bien, ahora vamos a escribir una historia para el estado enviado. Entonces, lo que voy a hacer es Exportar Consubmitted, Nueva Historia, y voy a copiar la función play de la primera, y corregir mis errores. Genial, ahora también voy a enviar, hacer clic en el botón, guardarlo, tengo una nueva historia. Y boom, tan pronto como lo abro, se envía el formulario y está hecho. Lo que realmente queremos hacer ahora es verificar que funcionó, que no solo termina en el clic del botón, verificar que funcionó usando una prueba. Y para hacer eso vamos a usar expect de Jest. Así que voy a importarlo, importar expect de storybook.jest. Nuevamente, necesitamos el envoltorio de storybook para Jest aquí porque es una versión instrumentada que funcionará con el complemento de interacciones. Entonces, lo que podemos afirmar aquí es el hecho de que se desencadenó una acción porque lo que sucede cuando se hace clic en el botón, se invoca este controlador de desenvío. Y eso es algo en lo que podemos afirmar usando expect. Entonces, esperar, expect, y luego podemos afirmar sobre los args. Y los args se pasan a lo largo de la función play. Así que voy a decir que se haya llamado a args.unsubmit. Guardar mi archivo. Veamos qué sucede. No se ha llamado. Nuevamente, esto se debe a que hay alguna validación asíncrona en su lugar, así que antes de que se llame al controlador de desenvío, lleva un poco de tiempo. En este caso, podemos solucionarlo usando la utilidad waitfor en la testing library. Waitfor, que toma una función, una función de devolución de llamada en realidad. Y ahora guardo mi archivo, y ahora funciona.

Bien, repasemos lo que hemos visto. La función play es solo una propiedad en tu storybook, y te permite ejecutar interacciones y hacer afirmaciones sobre tu componente. Para usar el complemento de interacciones, tendrás que usar los envoltorios de storybook para jest y testing library.

Este código realmente no se desvía mucho de la forma en que ya puedes estar usando la biblioteca de pruebas o una herramienta similar. Lo hemos diseñado para apoyarnos en los gigantes mientras brindamos más potencia y una mejor experiencia de usuario.

A estas alturas, es posible que te preguntes cómo lo logramos. Puede parecer mágico, pero en realidad estamos utilizando la intercepción y la intercepción en tiempo de ejecución. Dado que nos basamos en la biblioteca de pruebas y jest, estas bibliotecas están instrumentadas para funcionar con el complemento de interacciones. En tiempo de ejecución, se rastrean las invocaciones de métodos y se envían al panel del complemento para mostrar un registro de interacciones. Luego, cuando estás retrocediendo y avanzando con el depurador, en lugar de invocar el método de la biblioteca, devuelve una promesa que no se resolverá hasta que presiones Siguiente. Finalmente, para salir prematuramente de la función play, lanzamos excepciones que son ignoradas silenciosamente por Storybook. Puede sonar como algo malo, pero es el truco para que todo funcione.

Entonces, ¿cómo se integra esto con CI? Para eso, lanzaremos un ejecutor de pruebas Node.js que ejecuta todas las funciones play en tu Storybook utilizando un navegador sin cabeza. Y cuando algo falla, puedes revisar los errores en tu navegador habitual o enviar un informe a otras herramientas. De alguna manera, las historias siempre han sido como pruebas en Storybook. Con el complemento de Interacciones, solo lo llevamos al siguiente nivel y recién estamos comenzando. Gracias por escuchar, y por favor sígueme en Twitter si deseas recibir actualizaciones al respecto. Si tienes alguna pregunta, por favor encuéntrame en mi sesión de preguntas y respuestas. Muchas gracias por eso, Goert. Es una charla que definitivamente tendré que volver a ver porque no tuve la oportunidad de asimilarla lo suficiente como me gustaría. Y Storybook es algo que sigue llegando a mí por todas partes y no tengo la oportunidad de mirarlo lo suficiente.

Goert, te doy la bienvenida al escenario y veamos los resultados de tu encuesta. Pregunta fascinante. Prueba de extremo a extremo, 64%. ¿Qué opinas al respecto? En primer lugar, gracias por tenerme aquí. Estoy muy emocionado de hacer esto. Para ser honesto, no me sorprenden mucho los resultados de la encuesta porque, seamos honestos, TestJS Summit es, por supuesto, una audiencia bastante particular. Así que sospecho que muchas de estas personas están usando Cypress para sus pruebas porque, francamente, ese es el gran jugador, ¿verdad? Es muy popular y lo entiendo completamente. Así que no es sorprendente que obviamente hayamos tomado mucha inspiración de lo que han estado haciendo. Y, por supuesto, tenemos mucho respeto por lo que han hecho. Y estamos tratando de llevar parte de eso al universo de Storybook. Y, por supuesto, el universo de Storybook, como mencionaste, está creciendo muy rápido y es muy popular. Utilizado por miles de empresas en todo el mundo y todos están muy contentos al respecto.

Entonces, estamos tratando de agregar algo a esta mezcla aquí. Por eso quería hacer esta pregunta de encuesta, ¿cuál es la forma de probar la interfaz de usuario? ¿Cómo lo hacen las personas en este momento? La razón por la que estoy interesado en eso es porque, por supuesto, estamos tratando de ofrecer una forma nueva y adicional de hacerlo. Que está en el límite entre las pruebas de extremo a extremo y las pruebas unitarias. Y, por supuesto, también nos encantaría eliminar esa prueba manual para muchas personas. Porque también imagino que muchas personas están a punto de comenzar a hacer pruebas automatizadas. Pero todavía están atrapados con las pruebas manuales. Porque ciertas cosas son difíciles de probar o es una gran inversión, y cosas así. Creo que ciertas cosas solo se pueden probar de forma humana o manual. Pero lo fascinante que encontré aquí es que no fuiste muy específico con tu pregunta, ¿verdad? Así que todas las respuestas son correctas. Pero hay diferentes tipos de riesgos. Entonces, funcionalmente, Selenium y Cypress pueden ayudarte. Pero obviamente no es lo que ve el ser humano. Por lo tanto, la regresión visual y las pruebas manuales serán de ayuda. Así que pensé que era una gran pregunta. Una gran encuesta y resultados impresionantes.

Pero vamos a tener algunas preguntas del público para ti. Porque siempre pone al orador en apuros. Aquí es donde descubrimos qué sabe Gert. Tenemos una pregunta de Refactor Eric. ¿Qué navegadores son compatibles con las historias interactivas y las pruebas de interacción de Storybook? Excelente pregunta. Creo que prácticamente todos ellos siempre que ejecuten Storybook. Lo cual puede o no incluir Internet Explorer. No lo he probado, para ser honesto. Sospecho que no funcionará realmente. Storybook aún admite oficialmente Internet Explorer en la configuración particular. Pero nos estamos alejando de eso, por supuesto. Pero, por supuesto, estamos admitiendo prácticamente todos los demás navegadores actuales. Y eso se mantendrá. Porque simplemente se ejecuta en tu navegador y tenemos la intención de admitir a todos los principales proveedores.

Perfecto. ¿Tienes estadísticas? ¿Alguien todavía usa Internet Explorer para sus sitios web? Nosotros no, pero sabemos que otras personas sí lo hacen. Trabajo para Chromatic y ofrecemos Internet Explorer como una de las opciones de navegador para que nuestros clientes lo usen en las pruebas. Y todavía muchos clientes lo hacen. Así que todavía hay valor allí. Esa es la palabra correcta. Esa es la palabra correcta, para ciertas personas todavía hay valor en IE. Todavía está ahí. Todavía existe. Pero esperemos que esté en el – Sí. Tal vez deberíamos dejar de hablar de eso. ¿Verdad? Me siento mal incluso por mencionarlo, ¿verdad? Claro.

Otra pregunta de Jane Monroe. Storybook es genial para componentes individuales. ¿Y hay algún complemento para probar los componentes cuando se combinan? Básicamente, intentar probar como una página completa. Algo como un diseño completo de Figma.

Claro que sí. Sí. Entonces hay una gran cantidad de complementos en el ecosistema. Y una cosa en la que nos estamos enfocando mucho en este momento es hacer que sea más fácil y mejor construir componentes, o en realidad, historias, que compongan páginas completas, pantallas o asistentes. En realidad, aplicaciones completas.

Storybook es principalmente conocido por construir componentes de IU personalizados que encontrarías en, por ejemplo, una biblioteca de componentes o un sistema de diseño. Eso es por lo que es conocido. Pero el verdadero valor radica también en cuando comienzas a usarlo para el desarrollo de aplicaciones, donde construyes toda tu aplicación web en Storybook. De hecho, Chromatic en sí es una aplicación web muy complicada, un sistema muy complejo. Está completamente construido en Storybook.

Y volviendo a nuestra pregunta de la encuesta, en Chromatic confiamos en las pruebas de regresión visual para el 90% de nuestras pruebas, al menos para el front-end del sistema. Para el back-end, tenemos pruebas unitarias, etc. Pero el front-end es principalmente pruebas de regresión visual, y eso cubre prácticamente todo lo que necesitamos. Por supuesto, también tenemos algunas pruebas de extremo a extremo, solo para verificar, como una prueba de humo, para asegurarnos de que la cosa no esté caída, ¿verdad? Que funcione en absoluto. Pero el 90% son pruebas de regresión visual en nuestra situación, por supuesto, como prueba de uso propio, por supuesto. Bueno, como dije acerca de las pruebas de humo, solo asegurándonos de que todos los puntos estén conectados. Entonces, ya sabes, individualmente estás probando los puntos, ahora estás interesado en todo el flujo. Para dar una respuesta concreta a la pregunta, ¿qué complementos? Mock Service Worker es el que me viene a la mente, porque te permite simular solicitudes HTTP. Entonces, si construyes una página completa, esa página sin duda va a hacer algunas solicitudes HTTP para obtener algunos datos para alimentarla, ¿verdad? Entonces, Mock Service Worker te permite interceptar esa solicitud. No tienes que cambiar el código de tu aplicación para que esto suceda, porque vive en tu navegador e intercepta las solicitudes HTTP reales que tu aplicación está haciendo y devuelves datos simulados para que siempre sean estables, súper rápidos, sin errores, y así es como construirías una historia para una página compleja en Storybook. Fantástico, entonces Refactor Eric tenía una pregunta al respecto. Esperemos que nos hagas saber si eso responde a tu pregunta. No lo preguntaré, porque creo que sí. Julia Bond tiene una pregunta. ¿Qué pruebas debería reemplazar? Ellos creen que solo las pruebas unitarias. ¿Qué piensas, Gert? Bueno, yo diría que dependiendo de la forma en que hagas tus pruebas unitarias, tal vez. Pero diría que es una combinación. Está realmente en el límite entre tus pruebas unitarias y tus pruebas de extremo a extremo. Entonces, muchas cosas que tal vez escribirías una prueba de Cypress para probar cierto flujo en tu IU, puedes escribir pruebas de interacción en Storybook para eso.

Y pruebas unitarias, por supuesto, también. Muchas personas escriben sus pruebas unitarias en Jest con Testing Library, por ejemplo, para probar un componente de IU específico, como el estado interno de un componente de IU. Eso es algo que podrías o harías en Storybook. A medida que desarrollas el componente de IU, escribes una historia para él, espero que ya lo estuvieras haciendo. Lo único que haces ahora es agregar esta función play para agregar algunas afirmaciones, las afirmaciones que de otra manera irían en un archivo de prueba separado. Ahora ya no necesitas escribir ese archivo de prueba. Las colocas directamente en tu archivo de historia y obtienes muchos de esos beneficios, los mismos beneficios realmente, a un costo menor incluso ahora. Fantástico. Pregunta de nosotros mismos, ¿puedo usar interacciones de Storybook con algo que no sea Testing Library? Sí. Entonces, la cuestión es que nos estamos enfocando por ahora en Testing Library porque preguntamos en la comunidad y trabajamos con grandes empresas, y les preguntamos qué herramientas usan Y Testing Library realmente es el jugador dominante en las pruebas unitarias de tus componentes de IU pero también permiten escribir pruebas de interacción en una prueba unitaria. Por lo tanto, fue muy natural elegirlos como el objetivo principal para la integración. Sin embargo, lo hemos configurado de manera genérica para que cualquier biblioteca que pueda ser útil aquí pueda ser instrumentada, como lo llamamos, para trabajar con Storybook, con el complemento de interacciones. Entonces, como ejemplo, mientras estaba prototipando estas cosas, construí una integración para CHI, que es un tipo diferente de biblioteca de afirmaciones, solo por diversión para ver si funciona, ¿verdad? Y hay otro sistema de algunas personas de una empresa llamada Frontside que están construyendo una biblioteca llamada Interactors. Y de hecho, estamos trabajando con ellos para crear también una integración con esa biblioteca. Entonces, comenzamos con Testing Library y Jest Expect, o simplemente Jest, porque son los jugadores dominantes en este momento. Pero este es un ecosistema que solo va a crecer, y por supuesto, hemos diseñado este sistema de tal manera que es fácil de integrar con otras bibliotecas también, sí. Entonces, para resumir. Como mencionaste, va a crecer y mencioné al principio que sigo escuchando historias por todas partes. ¿Cómo se ve ese crecimiento? ¿Cómo crees que va a ser ese crecimiento? ¿Qué tan grande crees que va a ser? ¿Y qué tipo de crecimiento estás viendo? La cuestión es que todavía hay un gran campo por explorar, por así decirlo. Como mencioné, los sistemas de diseño son lo más importante en este momento, pero los desarrolladores de aplicaciones aún son un gran campo en el que apenas hemos incursionado. Entonces, ahí es donde se producirá el crecimiento principal y en eso nos estamos enfocando en este momento. Fantástico. Bueno, creo que nos has brindado mucha información, y espero que la audiencia de desarrolladores y probadores de aquí esté interesada en ver qué está por venir y qué está atrayendo. Si queremos estar al tanto de tus novedades, ¿estás en alguna red social? ¿Podemos seguirte y recibir actualizaciones al respecto? Sí, por supuesto. En mi charla lo mencioné, Scheehengeveld es mi nombre de usuario en Twitter. Es la primera letra de mi nombre y mi apellido. Encuéntrame y sígueme. Excelente, muchas gracias por tomarte el tiempo de venir a hablar con nosotros y compartir tus ideas, y espero verte de nuevo pronto. Gracias. Gracias.