1. Introducción y Antecedentes Personales
¡Hola! ¡Hola Kent, cómo estás? ¡Estoy muy bien! Es una hermosa mañana aquí en Utah, un poco lluviosa, pero a mi esposa le gusta la lluvia, así que estoy feliz. ¡Esposa feliz, vida feliz! Y, por supuesto, niños felices al manejar cuatro niños. Sí, como dije, es una locura manejar eso con tu carrera.
¡Hola! ¡Hola Kent, cómo estás? ¡Estoy muy bien! Es una hermosa mañana aquí en Utah, un poco lluviosa, pero a mi esposa le gusta la lluvia, así que estoy feliz. ¡Esposa feliz, vida feliz! Y, por supuesto, niños felices al manejar cuatro niños. Sí, como dije, es una locura manejar eso con tu career. Sí, son geniales! Sé que estás muy feliz con tus hijos, y yo también estoy feliz con mis hijos, por supuesto, pero ¿cómo estás manejando ahora con la pandemia? Probablemente están más en casa y manejar tu career ¿es difícil o está bien ahora? Sabes, ya estaba haciendo muchas cosas remotas antes de que golpeara la pandemia, muchos talleres remotos y cosas, así que la pandemia no afectó mucho mi career en ese sentido. Quiero decir que todos fueron afectados y mis hijos comenzaron a hacer la escuela en casa y todo, así que todo se sacudió pero sí, no fui tan afectado como todos los demás. Bueno, me alegra escuchar eso. Entonces, por mucho que me encantaría hablar de tus hijos, también tengo un hijo, y sí, me gusta hablar de eso, pero creo que nuestra audiencia no está aquí para hablar de tus hijos. Quieren hablar de testing, y hace unas semanas enviamos un tweet donde la gente podía hacer preguntas que quisieran que discutiéramos, y la primera es de
2. Migrating Projects to TypeScript
Estás migrando algunos de tus proyectos a TypeScript. Las migraciones siempre son difíciles, por lo que es importante considerar el tamaño de tu proyecto y la experiencia de tu equipo. Recomiendo comenzar con TypeScript flexible y agregar gradualmente reglas más estrictas con el tiempo. Evita la estrategia Big Bang para mantener buenas relaciones con tus colegas.
Peter Hozak. Estás migrando algunos de tus proyectos a
TypeScript. ¿Cuáles son los mayores desafíos para ti hasta ahora y qué puedes recomendar a las personas o equipos que aún no han decidido si comenzar la migración en sus proyectos? ¿Cuánto tiempo crees que llevará? Oh, eso dependerá del tamaño de tu proyecto y la experiencia de tu equipo, así que no puedo decirte exactamente cuánto tiempo llevará. Las migraciones siempre son realmente difíciles. Debes tener eso en cuenta. De hecho, tengo una publicación en el blog sobre la alineación entre ingeniería y negocios y lo importante que es que hagas lo mejor para el negocio, no solo lo que quieres hacer. Es en realidad una publicación bastante buena. Puedes echarle un vistazo en kentcdots.com slash blog. En cuanto a la recomendación, definitivamente lo recomiendo. Creo que es una gran idea. Hay algunas estrategias que puedes utilizar. Para ser claro, nunca he... Estoy tratando de recordar. Creo que en realidad migramos uno de nuestros proyectos en PayPal a Flow. Eso estaba en proceso cuando me fui. Pero aquí tienes un par de consejos. En primer lugar, no tiene que ser perfecto, especialmente si estás aprendiendo
TypeScript. No activaría el modo estricto. Es similar a agregar ESLint a un proyecto que nunca ha tenido linting. No recomendaría habilitar todas las reglas y corregirlo todo en un solo PR gigante, sino desactivar la mayoría de las reglas y luego, con el tiempo, agregarlas como advertencias y corregir cosas aquí y allá, y luego activarlas como errores o lo que sea. De la misma manera, haz que tu
TypeScript sea realmente flexible al principio, especialmente si no conoces bien
TypeScript. No quieres pasar mucho tiempo escribiendo tus tipos y terminar confundiéndote y escribiéndolos mal porque eres nuevo en
TypeScript. Así que usa unknown, usa any, lo que sea necesario para que funcione, y luego regresa más tarde cuando conozcas mejor
TypeScript. Sí, lo recomendaría. Lo recomendaría de forma iterativa con el tiempo en lugar de un solo PR gigante, pero sí, creo que es una buena idea. Sí, esa también es mi experiencia. Hacerlo de golpe, quiero decir, además de que requiere mucho trabajo de tu parte, vas a enviar ese PR a alguien y se convertirá en tu enemigo después de eso, ¿verdad? Si quieres mantener buenas relaciones con tus colegas, no hagas el Big Bang, incluso si es un proyecto pequeño, como migrar a
TypeScript, aunque sea muy valioso, es mucho trabajo y sí, no vayas con la estrategia del Big Bang.
Siguiente pregunta. Qué historia tan diferente. Estás haciendo el Big Bang con Prettier todo el día.
3. Next.js and Remix
Hoy en día, Next.js es un framework sólido que a mucha gente le encanta. Personalmente, estoy emocionado por Remix, que he estado usando para rediseñar mi sitio web personal. Remix tiene características únicas que lo hacen atractivo. No es solo una versión de pago de Next. Mi proyecto de Remix aún está en desarrollo intenso, pero se lanzará en uno o dos meses. No te perderás el anuncio si me sigues en Twitter o te suscribes a mi boletín.
La siguiente pregunta es de Behzad. Hoy en día,
Next.js se ve muy sólido, ¿deberíamos usar
Next.js en lugar de Create
React App o Create CSR? No estoy seguro de qué es CSR, pero sí,
Next.js es sólido. Lo siento, voy a hacer una pausa por un momento y quiero que también participes si vamos a hablar de
Next.js en el inicio de sesión del proveedor. Oh sí, claro. Entonces, sí,
Next.js es sólido. Lo usé hace años, en realidad no lo he usado recientemente, pero mucha gente lo usa y le encanta, y sí. Entonces, no creo que te equivoques al usar
Next.js como un
framework. Personalmente, estoy muy emocionado por
Remix. Durante los últimos meses, lo he estado usando para rediseñ
ar por completo mi sitio web personal. Estoy muy emocionado por una gran reescritura en la que estamos trabajando. Aún está en vista previa para desarrolladores. Tiene características que no encontrarás en ningún otro lugar y eso es lo que me atrae de él. No es solo una versión de pago de Next. Es muy diferente a eso, aunque a mucha gente le gusta decir eso, sin tener experiencia con
Remix. Pero Next es totalmente sólido. Si te parece interesante, adelante. ¿Tu proyecto de
Remix ya está en producción o todavía está en desarrollo? Todavía está en desarrollo intenso en este momento, pero hablamos de uno o dos meses antes de que salga y será genial. ¡Genial! Espero con ansias eso. Probablemente lo anunciarás en tu Twitter y en todos tus canales, por supuesto. Oh sí, no te lo perderás. Si me sigues en Twitter o te gusta o te suscribes a mi boletín o algo así, definitivamente te enterarás de esto. Sí, sé que cuando haces algo nuevo es difícil de pasar por alto. Eso es algo bueno. Porque siempre me gusta ver lo que estás haciendo.
4. Testing Library and Coverage
La biblioteca de pruebas es una nueva mentalidad para las pruebas de front-end. Se centra en las pruebas de integración y las pruebas de extremo a extremo, en lugar de probar componentes de nivel inferior con una lógica mínima. Las diferentes capas de pruebas se pueden comparar con pintar una pared, donde comienzas con una cobertura amplia y luego utilizas pruebas más detalladas para áreas específicas. No siempre es necesario tener una cobertura del 100%, excepto para las bibliotecas de código abierto. Es importante considerar el valor y el esfuerzo requerido para lograr la cobertura.
No me lo perdería por nada del mundo. La siguiente pregunta es de Carlos. ¿Es la biblioteca de pruebas una nueva mentalidad para las pruebas de front-end? Quiero decir, no pensamos en el comportamiento del usuario, por lo que tal vez no se trata de probar algún componente como un botón o incluso un hook y probarlo integrado en una página. Es más como una prueba de presión lateral, que te permite realmente entrar en un flujo. Sí, no suelo probar componentes de nivel inferior que no tienen mucha lógica porque es muy fácil cubrir esas cosas. Si tienes un pequeño botón o algo así, no me verías probando un botón a menos que haya alguna lógica complicada y sofisticada que no pueda cubrir fácilmente en una prueba de nivel superior. También tengo una publicación en mi blog sobre esto. Puedes encontrarla en kcd.im/trophy, donde describo las diferentes capas del trofeo de pruebas. Una cosa que menciono allí es una cita de una entrevista que está en testijavascript.com, donde básicamente se trata de pruebas. Estas diferentes capas de pruebas son como pintar una pared. La cita dice que puedes lanzar pintura contra la pared y eventualmente cubrirás la mayor parte de la pared, pero hasta que te acerques a la pared con un pincel, nunca llegarás a los rincones. Tu prueba de extremo a extremo es como lanzar un cubo de pintura contra la pared, pero eventualmente necesitas utilizar pruebas más detalladas. Tal vez tengas una pintura que hizo tu abuela o algo así, y no quieras ni siquiera pintar con un pincel grande. Utilizarás un pincel más pequeño para eso. Esa es la forma en que pienso en las diferentes capas de pruebas. No hay razón para utilizar un pincel pequeño para pintar toda la pared. Tomará demasiado tiempo obtener una cobertura completa. Pero sí, me enfoco más en las pruebas de integración como esa, como un rodillo de pintura. Cubres la mayoría de las cosas muy bien con eso, y también las pruebas de extremo a extremo, pero puedes utilizar la biblioteca de pruebas para todo esto. Eso es lo genial de la biblioteca de pruebas. Dondequiera que se encuentre el DOM, una prueba puede ayudarte a buscar elementos e interactuar con ellos.
Y mencionaste la cobertura. Y no creo que haya una respuesta real a esto, pero podemos preguntarlo de todos modos. ¿Cuál es una buena cobertura para la mayoría de los proyectos, dirías? ¿Siempre dirías 100%? En realidad, afirmaría que el número de cobertura del 100% es malo. Y tal vez no tan malo como el 0%, pero sí, sigue siendo malo la mayor parte del tiempo. Ahora, si estamos hablando de una biblioteca de código abierto, entonces sí, seguro. 100%. Eso suele ser relativamente fácil de lograr. Y hay una alta
Code Coverage and Career Advice
Para las aplicaciones, apuntar al 100% de cobertura puede llevar mucho tiempo y puede que no proporcione un alto retorno de inversión. La cobertura de casos de uso es una métrica mejor para considerar. Al observar el informe de cobertura de código, específicamente el informe de Jasmine, se puede identificar los caminos no probados. Es importante evitar escribir pruebas únicamente con el propósito de cumplir con los requisitos de cobertura. Sé amable y comunícate de manera efectiva para tener control sobre tu carrera y alcanzar tus metas en la industria tecnológica.
El valor para eso, porque este es un código altamente reutilizable. Entonces, es un poco diferente. Pero para las aplicaciones, si estás apuntando al 100% de cobertura, generalmente terminas gastando mucho tiempo extra probando cosas donde obtendrías un mayor retorno de inversión trabajando en características en su lugar. De hecho, tengo una publicación en mi blog sobre esto titulada Cómo saber qué probar. Y en eso, hablo sobre cómo la cobertura de código es una métrica útil, pero una mejor sería la cobertura de casos de uso, que no es realmente fácil de configurar como una métrica, pero es la forma en que debes pensar en tus pruebas. No suelo mirar mi informe de cobertura de código. La única vez que lo miro es solo para recordarme los casos de uso que puede que no haya cubierto, pero siempre estoy pensando en los casos de uso. Lo que realmente me gusta... Bueno, en realidad no se trata de la cobertura, pero si miras ese informe, creo que se llama informe de Jasmine, donde ves tu código y luego qué ramas no son tocadas por el código, por las pruebas. Esa es una forma en que realmente me gusta revisarlo y ver, oh, espera, este es un camino peligroso que no probé, y luego lo pruebo. Sí, exactamente. Así que eso es algo bueno. Y sí, como dijiste, ir realmente al 100% o cualquier porcentaje, he tenido empresas donde se estableció un porcentaje, y simplemente sabes que en cierto punto, estarás escribiendo pruebas solo para satisfacer tus necesidades de cobertura, aunque ya sepas que está bien. No necesito probarlo, pero sí, mi canal de integración continua fallará si no hago esa prueba. Sí, pero no vayas por ahí.
La siguiente pregunta es de Henrik. ¿Cuál es el mejor consejo que has recibido en tu carrera o en general? ¿Qué consejo darías ahora a alguien que está comenzando su carrera en tecnología? Gran pregunta, Henrik. Sí, esa es una excelente pregunta, Henrik. Creo que una de las cosas más importantes, lo primero que tengo que decir, es ser amable. No importa qué tan buen programador seas o qué tan bueno seas, ya sabes, las personas, sí, simplemente tienes que ser amable. Si las personas no quieren trabajar contigo, no obtendrás el trabajo que deseas. Entonces, si quieres tener control sobre tu carrera y realmente lograr cualquier objetivo que tengas, podrás hacerlo mucho mejor si eres una persona amable. Además de eso, diría que la comunicación es una habilidad realmente importante en la carrera porque incluso si eres el mejor programador del mundo, si no eres bueno comunicando lo que has logrado y cómo eso impactó en el negocio o mejoró la vida de las personas, eso también dificultará que obtengas el trabajo que deseas. Esto se ve a menudo en personas que son realmente buenas en algo o al menos son las que no se quejan de hacer algo y, por lo tanto, obtienen todo ese trabajo cuando en realidad quieren hacer otra cosa. Entonces, necesitas poder comunicar cuáles son tus metas en la carrera y cuáles son tus logros. Simplemente te emocionas mucho por las cosas que quieres seguir haciendo y dices, mira esta cosa genial que hicimos. Me encantaría seguir haciendo esto o hey, esto es algo genial que hicimos, pero no me interesa mucho eso. ¿Podría comenzar a hacer más del lado del front-end o del lado del back-end o lo que sea? La comunicación ha sido una herramienta realmente, realmente útil para mí. Sí. Me encanta que estés diciendo eso en una conferencia de tecnología, que no mencionas ninguna tecnología, solo sé una persona amable y me encanta esa respuesta. Gracias. Voy a ver nuestro canal de Discord, cuál es la opinión de nuestra audiencia, la audiencia en vivo.
Pruebas RTL y React Testing Library
Al probar diferentes ubicaciones geográficas, asegúrate de que tu aplicación no se rompa. Para la funcionalidad RTL, utiliza herramientas de prueba de regresión visual como applitools o perci.io para reducir la inconsistencia. Netflix ha compartido su enfoque para las pruebas RTL en una publicación de blog. React Testing Library es una colección de utilidades de JavaScript que se prueban utilizando Jest, que utiliza Jest para probarse a sí mismo.
... agregando
testing para diferentes ubicaciones geográficas y por eso no me molesto. Pero RTL es definitivamente una característica que no quieres que se rompa. Y si eso es algo que es realmente importante para ti y tu negocio, entonces probablemente quieras optar por la prueba de regresión visual. Y eso es ... Estamos hablando de herramientas como applitools o perci.io, donde ellos utilizarán su inteligencia artificial sofisticada para determinar la forma correcta de realizar la prueba de regresión visual. Porque no sé acerca de los demás, pero la prueba de regresión visual es conocida por ser muy complicada, inconsistente y es por eso que estas tecnologías han avanzado lo suficiente para reducir la inconsistencia de este tipo de pruebas. Y así es como abordaría la prueba de RTL, si eso fuera una parte realmente crítica de mi negocio.
Pruebas RTL y React Testing Library
Las pruebas RTL implican agregar un 20% más de caracteres a las cadenas de texto para asegurarse de que la interfaz no se rompa con cadenas de texto más largas. Consulta el blog de ingeniería de Netflix para obtener más detalles. Percy.io es otra herramienta mencionada. React Testing Library es una colección de utilidades de JavaScript que inicialmente se crearon para uso personal y luego se convirtieron en una biblioteca. Son principalmente utilidades de JavaScript y diferentes de un marco de pruebas. Jest utiliza Jest para probarse a sí mismo. Las pruebas para React Testing Library se asemejan a la forma en que se utiliza el software, incluidas las pruebas de integración.
Sí. Bueno, por supuesto, hay muchas empresas a las que les importa. Lo que sé sobre las pruebas RTL es la publicación de Netflix. Tiene unos dos años y compartieron su enfoque de agregar, creo que un 20% más de caracteres en cada cadena, solo para asegurarse de que si hay un idioma en el que la cadena sea más larga, la interfaz no se rompa. Así que eso es, no sé si has visto esta publicación en el blog, pero eso es algo que, si quieres hacer pruebas RTL, te recomendaría buscar en el blog de ingeniería de Netflix, que también es un buen blog para seguir. Percy.io es la otra herramienta que mencionaste. Pregunta de Luke, ¿la biblioteca de pruebas de
React se prueba a sí misma? ¿Cómo pruebas tu biblioteca de pruebas? Sí, claro. Bueno, piensa en ello, el código de pruebas no es diferente de cualquier otro código, como de hecho, incluso la prueba que estás escribiendo, eso es solo código. Y podrías escribir pruebas para eso. Podrías tomar tu bloque de función de prueba, podrías poner eso en una función y llamar a esa función y hacer afirmaciones sobre lo que hace. Así que, es solo código. Y cuando estás escribiendo un montón de pruebas, eventualmente llegas a algunas utilidades que pueden ser útiles o no para cualquier otra persona. Y eso es lo que es la biblioteca de pruebas de
React, es un conjunto de utilidades que yo escribí para mí mismo y pensé, wow, estas son realmente útiles. Hagamos una biblioteca con esto. Y luego enseñ
ar a la gente cómo usarlo. Y eso es testingjavascript.com. Así que sí, definitivamente se prueba a sí misma. Es principalmente utilidades de
JavaScript. Y por lo tanto, es muy diferente de un marco de pruebas. Pero incluso el marco de pruebas en sí mismo también se prueba. Eso es realmente interesante, porque Jest utiliza Jest para probar sí mismo. Y sí, ahí es donde las cosas se vuelven un poco meta. La biblioteca de pruebas de
React no utiliza la biblioteca de pruebas de
React para probarse a sí misma exactamente. Quiero decir, llamamos a render cuando estamos probando la función de renderizado. Llamamos a, ya sabes, get by text y cosas así y get by role y todo eso. Para asegurarnos de que esté haciendo lo que se supone que debe hacer la mayor parte del tiempo, en general, recomiendo que tus pruebas se parezcan a la forma en que se utiliza el software. Y por lo tanto, nuestras pruebas para la biblioteca de pruebas de
React también lo hacen. Así que si revisas las pruebas de la biblioteca de pruebas de
React, probablemente encontrarás algunas que son para utilidades de nivel inferior que son pruebas de unidad más bajas nivel que no escribirías. Pero muchas de ellas son pruebas de integración. Se verán
Pruebas de Integración y Bibliotecas de Componentes
Si nuestras pruebas pasan, asumimos que no romperemos tus pruebas. Jest utiliza Jest para probar su código. Las pruebas de integración son importantes para las bibliotecas de componentes. La línea entre las pruebas de integración y las pruebas unitarias se vuelve borrosa. Me enfoco en las pruebas de integración para las bibliotecas de componentes. Si defines una prueba unitaria como solo la unidad, entonces una biblioteca de componentes no tendría muchas pruebas unitarias. Vamos más allá de las bibliotecas de componentes hacia un sistema de diseño, que es simplemente una colección de componentes.
muy similares a los tipos de pruebas que escribirías. Y si nuestras pruebas pasan, asumimos que no romperemos tus pruebas. Esperemos. Esperemos. Bueno, la ciencia es un poco aterradora. Como dijiste, Jest utiliza Jest para probar su código, porque si Jest se rompe, ¿las pruebas también se romperán? Sí, ¿cómo lo sabes? Sí. Creo que hay algunos lenguajes que se escriben a sí mismos también. No sé cómo se inicia eso, pero eventualmente cambian a su propio lenguaje para escribir su lenguaje, lo cual es interesante. Eso es muy meta. Tenemos una pregunta de Sasha. ¿Crees que las pruebas de integración también son importantes además de las pruebas unitarias para las bibliotecas de componentes? ¿Y qué opinas de las pruebas de integración en general? Sí, bueno, tengo una publicación de blog que es bastante popular sobre este tema llamada `Escribe pruebas, no demasiadas, principalmente de integración`, que es una cita de Guillermo Rausch de hace años. Y sí, puedes echarle un vistazo. Es kcd.im/escribe-guion-prueba. Y por lo tanto, el trofeo de las pruebas está inclinado hacia las pruebas de integración. Me enfoco en las pruebas de integración para las bibliotecas de componentes. La línea entre las pruebas de integración y las pruebas unitarias se vuelve un poco borrosa. Algunas personas dicen que una prueba unitaria es solo la unidad. Simulas todo lo que la rodea. Y si eso es cómo defines una prueba unitaria, entonces no escribo muchas de esas en absoluto. Y la mayoría de ellas son como, tengo una función pura. Es bastante complicada. Solo probémosla por sí misma. Y esa sería mi forma de prueba unitaria. Entonces, si eso es cómo defines una prueba unitaria, entonces en una biblioteca de componentes, prácticamente no usaría casi ninguna prueba unitaria. Todo sería integración. Quiero renderizar el componente. Quiero interactuar con ese componente. Y sí, por lo tanto, dedico la mayor parte de mi tiempo al espacio de integración.
Entonces, vayamos un paso más allá de las bibliotecas de componentes. Digamos que tienes un sistema de diseño. Entonces,
Pruebas de Sistema de Diseño y Pruebas de Instantáneas
¿También agregarías pruebas para un sistema de diseño? En PayPal, fui responsable de construir un sistema de diseño y probé cada componente. Creo que tener una prueba que verifique si el componente se renderiza es de bajo costo y asegura que no haya errores de sintaxis. Las pruebas de instantáneas son solo afirmaciones, pero pueden incluir información irrelevante. Rara vez uso instantáneas para las pruebas de interfaz de usuario y prefiero eliminar los datos irrelevantes de las instantáneas.
Es solo una colección de componentes al final. ¿También agregarías pruebas para un sistema de diseño entonces? Sí. Entonces, no estarías probando ese botón. Sí. Sí. Y, de hecho, en PayPal, fui responsable de construir eso. Eso fue lo último en lo que trabajé antes de irme. Y sí, estaba probando cada componente. Pero siempre había lógica que estaba probando allí. Y cuando es un sistema de diseño o una biblioteca de componentes y tienes un botón, al menos tendría una prueba que diga que esto se renderiza porque es tan económico tener ese tipo de prueba. Y debido a que es un sistema de diseño o una biblioteca de componentes reutilizable, quiero asegurarme de que no tenga un error de sintaxis o algo así. Quiero decir, estaba en
TypeScript. Entonces, la probabilidad de tener un problema es bastante baja, pero. Pero entonces, ¿dirías que una prueba de instantánea sería suficiente? Sí, pruebas de instantáneas. Tengo una publicación de blog sobre esto llamada `Pruebas de instantáneas efectivas`. Sí, tal vez en bibliotecas de componentes. Lo que sucede es que las instantáneas son solo afirmaciones. No son diferentes de cualquier otra afirmación. Entonces, cuando tienes una afirmación, quieres que cuando falle, sepas por qué falló tanto como sea posible. Ese es tu trabajo como escritor de afirmaciones. Y cuando tomas una instantánea, puedes tomar una instantánea del mundo que podría incluir dónde está el sol y qué sistema operativo estás ejecutando. Literalmente, todo. Y este es el estado del mundo. Esa no sería una prueba de instantánea útil. Por supuesto, no hacemos eso. A menudo, veré instantáneas que tienen cientos de líneas. Lo que estoy diciendo es que una instantánea a menudo incluye mucha información que es totalmente irrelevante para la prueba. Por lo tanto, rara vez uso instantáneas para las pruebas de interfaz de usuario. Es muy raro que me veas hacer eso. Lo que hago es, si quiero comenzar con una instantánea, eliminaré lentamente todas las cosas en la instantánea que sean irrelevantes.
Writing Tests and Communication Resources
Al escribir pruebas, es importante enfocarse en el resultado deseado y hacer afirmaciones claras. Escribir pruebas es como escribir una prueba para asegurarse de que el código funcione como se pretende. También es interesante destacar que algunos lenguajes de programación están escritos en el mismo lenguaje en el que se implementan. En cuanto a los recursos de comunicación, la práctica es clave y compartir tu trabajo puede ser beneficioso.
Entonces, encontraré el elemento en el que estoy tratando de hacer una afirmación. Y luego me doy cuenta, oh, todo lo que me importa es que este atributo sea, ya sabes, este cierto valor. Y así, en lugar de hacer una instantánea, simplemente haré una afirmación en ese atributo. Sí, puedes leer más al respecto en mi publicación de blog sobre instantáneas. Sí. Entonces, si realmente quieres, digamos que volvemos a un botón y quieres probar si acepta un nombre de clase, tu componente para ese botón, entonces puedes hacerlo con una instantánea, pero si la prueba de instantánea falla, sí, ya no sabes qué estás probando a menos que hayas escrito una descripción realmente buena, así que es mejor simplemente decir que debería aceptar el nombre de la clase y luego, oh, estoy fallando con la sintaxis de mi biblioteca de pruebas en mi cabeza. Iba a escribirlo. Simplemente seleccionas el botón y dices que debe tener el nombre de la clase y luego es muy claro, como le paso este nombre de clase, espero que tenga el nombre de la clase. Si eso falla, entonces quien lo lea, incluso si soy yo en seis meses, sé exactamente por qué falló esto. Sé exactamente cuál es el objeto. Puede que no sepa por qué sucedió, pero sé cuál es el resultado deseado. Sí, eso es un buen punto. A veces incluso estás escribiendo pruebas para ti mismo. Siempre que escribo pruebas, tengo una cita de un amigo mío, Frank de Jonge, y una vez tuiteó, No escribo pruebas, escribo pruebas. Y eso siempre es como si estuviera demostrando a mí mismo que esto funciona como yo pretendía. Y realmente me gusta esa mentalidad para mí mismo. Así que sí, eso me parece bien. A continuación, tenemos a mucha gente mencionando, por cierto, como Go está escrito en Go, C está escrito en C.
TypeScript está escrito en
TypeScript. Así que es realmente genial tener esa interacción. Es un poco confuso para mí. Juan está pidiendo un seguimiento sobre el consejo de comunicación. ¿Qué recursos de comunicación recomendarías? Bueno, gracias, Juan. Supongo que la práctica. No tengo ningún recurso para ofrecer. Estoy seguro de que hay libros y cosas así. Esto es algo que me viene naturalmente. Tal vez soy un poco molesto, pero comparto todo. Esa es la razón, a menudo, por la que la gente piensa
Sharing and Poll Results
Entonces, puede que no esté haciendo más que nadie, pero simplemente comparto todo. Un podcast que me viene a la mente es el Soft Skills Engineering. Realmente amo ese podcast. Es hilarante. Solo eso. El valor de entretenimiento es bueno por sí solo, pero también tienen muy buenos consejos, a menudo sobre comunicación. Tomemos un momento para revisar los resultados de la encuesta. Kent ha preguntado qué porcentaje de tiempo estás dedicando a las diferentes cosas de las pruebas y el ganador es Hooks. 100% con un 46%. Eso se siente realmente extraño. 100% pero 64% lo siento. En números holandeses, lo dijiste al revés. Lo siento. Siempre es difícil para mí. He estado haciendo esta encuesta en Twitter a lo largo del tiempo, desde que se lanzaron los Hooks cada pocos meses, haré esta encuesta. Y está yendo constantemente en la dirección en la que muy pocas personas no están usando, principalmente, Hooks. Y por eso eliminé por completo las clases de todos mis componentes de clase y de todo mi material de enseñanza tan pronto como salieron los Hooks. Pensé, ya no enseñaré eso. Puedes ver mis cosas antiguas si quieres aprender sobre clases. Ahora estoy 100% en Hooks en todas partes. Bueno, eso es bueno. Hay que mantenerse al día con las cosas modernas.
La razón por la que hago tanto es porque literalmente comparto todo lo que hago. Entonces, puede que no esté haciendo más que nadie, pero simplemente comparto todo. Sí. Realmente no tengo ningún consejo específico. Bueno, no sé, esto puede que no esté totalmente relacionado, pero un podcast que me viene a la mente es el
Soft Skills Engineering. Realmente amo ese podcast. Es hilarante. Solo eso. El valor de entretenimiento es bueno por sí solo, pero también tienen muy buenos consejos, a menudo sobre comunicación. Muy bien. ¿Te importaría compartir un enlace con eso en Discord más tarde para que Juan pueda encontrarlo y el resto de nuestra audiencia también, por supuesto, y para seguir desde mi lado, simplemente habla con la gente. Si quieres saber si a la gente le gustas, probablemente obtendrás una respuesta justa si te acercas a ellos uno a uno, pero puede que sea aterrador. Así que sí, si no te gusta eso, lo entendería. Sí. Tomemos un momento. Estamos llegando al final de nuestra charla. Para asegurarnos de que no nos pasemos de tiempo, tomemos un momento para revisar los resultados de la encuesta. Entonces, Kent ha preguntado qué porcentaje de tiempo estás dedicando a las diferentes cosas de las pruebas y el ganador es Hooks. 100% con un 46%. Eso se siente realmente extraño. 100% pero 64% lo siento. En números holandeses, lo dijiste al revés. Lo siento. Siempre es difícil para mí. Entonces, Kent, ¿esto es lo que esperabas? He estado haciendo esta encuesta en Twitter a lo largo del tiempo, desde que se lanzaron los Hooks cada pocos meses, haré esta encuesta. Y está yendo constantemente en la dirección en la que muy pocas personas no están usando, principalmente, Hooks. Y por eso eliminé por completo las clases de todos mis componentes de clase y de todo mi material de enseñanza tan pronto como salieron los Hooks. Pensé, ya no enseñ
aré eso. Puedes ver mis cosas antiguas si quieres aprender sobre clases. Ahora estoy 100% en Hooks en todas partes. Bueno, eso es bueno.
Uso de TypeScript y Pruebas de Linting
Preguntaste si deberías escribir TypeScript para tu material en Twitter. Definitivamente estoy utilizando TypeScript para todo mi contenido. Estoy en proceso de convertir todo Epic React a TypeScript al 100%. Haré un curso de TypeScript o una serie de masterclass. También tengo un script que eliminará todo el TypeScript. TypeScript mejora la experiencia de aprendizaje con el autocompletado. Otra pregunta de Luke sobre las pruebas de linting. Recomiendo usar un plugin de linter para la biblioteca de pruebas y escribir tus pruebas. Desafortunadamente, el orador no puede continuar en el chat espacial. Gracias por unirte.
Hay que mantenerse al día con las cosas modernas. Y no quieres escribir algo que la gente ya no esté usando. Así que eso es genial. También recuerdo que hace unos meses, o tal vez hace más de un año, preguntaste si deberías escribir
TypeScript para tu material en Twitter. ¿Cuál fue el resultado de eso? ¿Qué le gustó a la gente? Sí. Bueno, a veces hago encuestas solo porque me interesa lo que la gente dice, no porque vaya a cambiar lo que hago. Así que sí, hago lo que quiero y las personas que están de acuerdo con eso me seguirán. Pero sí, definitivamente estoy utilizando
TypeScript para todo mi contenido. Estoy en proceso de convertir todo Epic
React a
TypeScript al 100%. Tendré que volver a grabar los 350 videos para eso, lo cual no será divertido. Haré un curso de
TypeScript o una serie de masterclass para las personas. Así que si aún no has utilizado
TypeScript, puedes hacerlo a través de eso. También tengo un script que eliminará todo el
TypeScript. Así que si no quieres usar
TypeScript, también puedes hacer eso. Pero simplemente creo que
TypeScript mejora aún más la experiencia de aprendizaje porque obtienes autocompletado y eso es un beneficio enorme mientras aprendes. Así que sí,
TypeScript todo el camino. Muy bien, genial. Otra pregunta de Luke. Un minuto, así que sé rápido. ¿Cuál es tu opinión sobre el linting de tus pruebas? Hago el linting de mis pruebas. Hay un plugin de linter para la biblioteca de pruebas que puedes revisar. Creo que realmente hay uno. Así que recomendaría usar eso para tus pruebas. Te ayuda a escribir mejores pruebas. También escribo mis pruebas en
TypeScript. A veces puede ser un poco molesto, pero encuentras formas ingeniosas de hacerlo, especialmente con funciones simuladas y módulos simulados. Pero sí, recomiendo escribir tus pruebas con tipos y hacer el linting de tus pruebas. Wow, no me lo esperaba, para ser honesto. Bueno, como ese fue nuestro último momento, mi memoria está fallando. ¿Tienes una sala de oradores disponible? ¿Pueden las personas continuar la conversación? Estaré en el chat espacial para que la gente pueda hablar conmigo justo después de esto. Genial. Bueno, eso es todo para nuestra pequeña charla junto al fuego, Kent. Muchas gracias por unirte. Me divertí un poco y sí, desafortunadamente no puedo continuar en el chat espacial porque me necesitan aquí. Pero sí, espero verte de nuevo pronto. Sí, igualmente. Muchas gracias. Ha sido un placer.
GraphQL Galaxy 2021
DevOps.js Conf 2021
Vue.js London Live 2021
JSNation Live 2021
