a11y y TDD: Una Combinación Perfecta

Rate this content
Bookmark

La accesibilidad ha sido el patito feo del desarrollo web durante mucho tiempo. A menudo me preguntan: "¿cuándo deberías probar la accesibilidad en tus aplicaciones?" Mi respuesta es simple: "¡desde el principio!". Independientemente del framework considerado - React, Svelte, Vue, YourOwn™️ - como desarrolladores, estamos en una posición privilegiada para ayudar al patito feo a convertirse en un hermoso cisne. ¿Cómo? Sumergiéndonos en el estanque y aprovechando el poder de las APIs de Javascript para construir los componentes adecuados para nuestras aplicaciones web. ¿Y cómo puedes saber si los estás construyendo correctamente? Combinando el Desarrollo Dirigido por Pruebas con la familia de bibliotecas de pruebas. ¿Listo para convertir tus aplicaciones web en cisnes?

24 min
16 Jun, 2022

Video Summary and Transcription

Esta charla explora la intersección entre la accesibilidad y el desarrollo dirigido por pruebas (TDD) en el desarrollo de software. TDD es un proceso que implica escribir pruebas antes de escribir código de producción, proporcionando una red de seguridad para los cambios de código. La charla demuestra cómo aplicar los principios de TDD a ejemplos de la vida real, como completar un formulario, y enfatiza la importancia de las pruebas centradas en el usuario. Mediante el uso de los principios de diseño atómico, el código puede organizarse de manera limpia y sencilla. La charla también discute el uso de etiquetas y IDs de prueba en las pruebas para mejorar la accesibilidad.

Available in English

1. Introducción a la Charla

Short description:

Bienvenidos a esta charla. Mi nombre es Rita y trabajo en el SDC, el centro de desarrollo de software del Grupo Volkswagen en Lisboa. En mi tiempo libre, me gusta jugar. Si alguna vez están en Lisboa, por favor, pasen por nuestro edificio.

De acuerdo. Muchas gracias. Bienvenidos a esta charla. Y empecemos. Mi nombre es Rita. Soy una apasionada de la tecnología. Realmente amo los cómics. Tengo un hijo llamado Pedro. Tiene tres años y medio. Recientemente, desde que volvimos de la pandemia, empecé a andar en bicicleta. Y cuando voy al trabajo, suelo hacerlo en bicicleta. En mi tiempo libre, me gusta jugar, lo cual es agradable. Trabajo en el SDC con estas personas increíbles, que son las que están haciendo ruido. Y el SDC es el centro de desarrollo de software del Grupo Volkswagen en Lisboa. Este es nuestro edificio. Es realmente bonito. Si alguna vez están en Lisboa y quieren visitarnos, por favor, pasen por aquí.

2. Accessibility and Test-driven Development

Short description:

Entonces, hoy hablaremos de accesibilidad. Ya se ha hablado de ello en charlas anteriores. La primera definición que encontrarás en el diccionario para accesibilidad es algo que es capaz de ser entendido, apreciado y alcanzado. ¿Qué es el desarrollo guiado por pruebas (TDD)? En pocas palabras, es la capacidad de convertir los requisitos del software en casos de prueba antes de escribir cualquier línea de código de producción. Entonces, dada la accesibilidad y el TDD, ¿cómo se relacionan exactamente estos dos conceptos y por qué es tan importante combinarlos? Volvamos a la accesibilidad. Para nosotros, los desarrolladores, la accesibilidad es el poder permitir que la mayor cantidad de personas posible utilicen el software que usamos, empoderar a las personas para que utilicen las cosas que construimos. La accesibilidad es para todos nosotros. Incluyéndonos a nosotros. ¿Cuántos de ustedes tienen problemas con el teclado? Y la accesibilidad nos brinda esto. Volviendo al desarrollo guiado por pruebas. Mi primer contacto con el TDD fue a través de este libro.

Entonces, hoy hablaremos de accesibilidad. Ya se ha hablado de ello en charlas anteriores. Y hay una gran razón para ello. Así que cuando piensas en accesibilidad, generalmente piensas en personas con discapacidades, o algo que puede ser accesible para personas con discapacidades, o algo que está adaptado para personas con estas discapacidades. Sin embargo, eso no es todo. La primera definición que encontrarás en el diccionario para accesibilidad es algo que es capaz de ser entendido, apreciado y alcanzado, lo cual es importante. Deja que eso se hunda.

¿Qué es el desarrollo guiado por pruebas (TDD)? En pocas palabras, es la capacidad de convertir los requisitos del software en casos de prueba antes de escribir cualquier línea de código de producción. Es bastante simple y solo para tener una idea de la sala, ¿cuántos de ustedes han hecho desarrollo guiado por pruebas? OK, genial. Entonces los dejaré ir. Luego avanzaré rápidamente. Pero para aquellos de ustedes que no lo han hecho, el desarrollo guiado por pruebas es... lo siento.

Entonces, dada la accesibilidad y el desarrollo guiado por pruebas, ¿cómo se relacionan exactamente estos dos conceptos y por qué es tan importante combinarlos? Espero que al final de esto tengas una mejor idea al respecto. Volvamos a la accesibilidad. Y algo curioso que descubrí. Entre la A y la Y, hay 11 letras. Y por eso se le suele llamar LE o A11Y. No lo sabía, pero una vez que lo supe, se convirtió en un dato curioso. Para nosotros, los desarrolladores, la accesibilidad es el poder permitir que la mayor cantidad de personas posible utilicen el software que usamos, empoderar a las personas para que utilicen las cosas que construimos. No queremos construir cosas para que se guarden en un estante. Pero no solo es para personas en silla de ruedas, que usan muletas o que tienen un carrito de ruedas para bebés. La accesibilidad es para todos nosotros. Incluyéndonos a nosotros. Especialmente a nosotros. ¿Cuántos de ustedes tienen problemas con el teclado? Si podemos pasar todo nuestro tiempo usando solo el teclado, eso es genial. Y la accesibilidad nos brinda esto. Volviendo al desarrollo guiado por pruebas. Mi primer contacto con el TDD fue a través de este libro. Está hecho para Java.

3. Introducción a TDD

Short description:

TDD está compuesto por un ciclo rojo donde escribes una prueba, la haces fallar, implementas código de producción para que pase y refactorizas si es necesario. Proporciona una red de seguridad para los cambios de código. TDD se puede aplicar más allá del desarrollo de software, como pelar una patata, utilizando el patrón 3A: organizar, actuar y afirmar.

Está escrito con ejemplos en Java. Es bastante completo. Está super, super bien estructurado. Y nos da las bases de lo que es TDD.

Entonces, en pocas palabras, está compuesto por esa ronda mágica que les mostré. La primera parte es el ciclo rojo. O la parte roja del ciclo. Escribes una prueba. La haces fallar. Implementas solo suficiente código de producción para que la prueba pase. Si es necesario, refactorizas tanto la prueba como tu código. A veces las cosas se hacen más o menos bien al principio y no es necesario refactorizar. A veces es necesario refactorizar. Tenlo en cuenta. Y con el ciclo de TDD, siempre tendrás una red de seguridad en los cambios que hagas en tu código.

Pero seguro que puedes decir, bueno, eso es muy fácil cuando estás haciendo desarrollo backend. ¿Qué pasa con el desarrollo frontend? No sé exactamente cómo funcionan las cosas en el frontend. ¿Cómo pruebo las cosas? ¿Cómo debo hacer clic en las cosas? Bien. Entonces, piensa en TDD no solo como una metodología para el desarrollo de software. Piensa en ello como una forma de aplicar las cosas. Por ejemplo, una patata. Si quieres pelar una patata y si queremos crear una historia de usuario que vaya en la línea de que el usuario quiere poder pelar una patata. Si quieres ir directamente a pelar la patata, comenzarás a pensar cosas como, ¿lo haré con un cuchillo? ¿Lo haré con qué tipo de cuchillo? ¿Debo usar un pelador de patatas? ¿Debo usar un pelador de patatas que sea uno de esos que haces así y que la sierra sea así o sea así? No importa realmente. ¿Deberías hervir la patata y luego pelarla porque la parte exterior se desprende fácilmente así. Deberías pelarla de arriba a abajo o de abajo a arriba. No importa realmente. ¿Por qué no importa? Porque al final del día, lo que quieres hacer es pelar la patata. Así que puedes convertir esto en una prueba. Así que sigues el patrón 3A. Organizas, actúas y afirmas sobre tu objeto.

4. Rellenando un formulario con pruebas

Short description:

Obtienes una patata. La pelas. Está pelada. Es muy simple. Pero, ¿qué pasa si tomamos un ejemplo de la vida real? Imagina que tienes un formulario y te piden que completes algunos datos personales. Comienzas a completarlo, pero terminas yendo por el camino equivocado. Para completar el formulario, necesitamos escribir una prueba que cubra el recorrido del usuario.

Obtienes una patata. La pelas. Está pelada. Es muy simple. Te enfocas en tu forma de cocinar y no te pierdes en los detalles. Vas directo al punto y haces solo lo necesario para pelar la patata.

Entonces, esto está muy bien con la patata. Pero, ¿qué pasa si tomamos un ejemplo de la vida real? Imagina que tienes un formulario y imagina que dentro, déjame encontrar el ratón que está aquí, déjame encontrar eso dentro de este formulario, te piden que completes algunos data personales. Has encontrado la cadena que dice `ingresa tu nombre`, comienzas a completarlo. Presionas tabulador, tabulador, tabulador para completar el formulario.

¿Irás o no irás? Sí, está bien. Iremos. ¡Oops! Camino equivocado. No es la forma en que queremos ir. ¿Iremos al día de reunión? Sí. Seguro. ¿Cómo? En barco. De acuerdo. Si vamos en barco, se completa todo el formulario. De acuerdo. Necesitamos hacer clic. De acuerdo. Necesito hacer clic en este botón que dice algo. Genial. El flujo está completo. Acabo de contarte una historia. Esta es la historia de usuario que tendremos que completar en este formulario. ¿Cómo podemos hacer esto? Podemos escribir una prueba y cubrir este recorrido de este usuario que seremos nosotros.

5. Organizando el código con Atomic Design

Short description:

Exploraremos cómo pasar de un diseño de formulario a un proyecto completamente organizado con Atomic Design. Al aplicar Atomic Design, podemos organizar nuestro código de manera limpia y sencilla. Comenzaremos con la molécula de entrada de texto y escribiremos una prueba para asegurarnos de que tenga los elementos requeridos. Una vez que la prueba pase, podemos proceder a escribir el código necesario.

Todo lo que les he contado está mapeado en este pseudocódigo o en estos comentarios. Así que empecemos. ¿Cómo vamos a pasar exactamente de un formulario que en este caso tiene algunos diseños o interfaces visuales a un proyecto completo, a un proyecto que tiene, no lo tiene. Creo que debería tenerlo, sí lo tiene. ¿Cómo pasamos de un formulario que tiene, de los diseños a un producto, a un proyecto que tiene la carpeta de origen, que está organizado con pequeñas cosas, cosas incrementales, que tiene pruebas que eventualmente tendrán un recorrido de usuario de principio a fin.

¿Cómo podemos organizar las cosas? Podemos hacerlo aplicando un patrón de diseño atómico. Puedes ser engañado por el nombre que dice diseño atómico, por lo que debe estar dirigido a diseñadores. Lo está. Pero podemos aprovechar el poder que el diseño atómico proporciona y aplicar el mismo patrón en el software que construimos. Entonces, cuando estamos construyendo el software, organizamos nuestros componentes por complejidad. Tenemos los elementos más simples posibles. Etiquetas HTML que se consideran átomos. Comienzas a combinarlos para formar moléculas. Comienzas a combinar moléculas para formar organismos, y luego tienes el último par en la jerarquía que son las plantillas y las páginas. Puedes pensar en las páginas como plantillas instanciadas. No voy a entrar en detalles sobre la parte del diseño atómico porque por sí sola, es un tema enorme para hablar. Pero solo quiero darte la idea de que es posible organizar nuestro código de una manera muy atómica y limpia para facilitar la incorporación de nuevas personas.

Comencemos con algo. La molécula de entrada de texto. Desde el diseño, la molécula de entrada de texto es algo muy simple. Tiene el texto `Tu nombre` y tiene un cuadro de entrada. Muy bien, escribamos una prueba para eso. La prueba consistirá en verificar que tenga el título y la entrada. Utilizaremos componentes web para la demostración. Generaremos un HTML con el componente web mencionado y dentro del HTML, esperaremos encontrar un párrafo con el texto que queremos y una entrada. Ejecutamos la prueba y cuando la ejecutamos, aparece en rojo, porque por supuesto no hay código de producción que respalde la prueba que acabamos de hacer. Así que vamos a ampliar. Escribamos la cantidad justa de código para que nuestra prueba pase. Que es solo esto. Nada más.

6. Añadiendo flexibilidad a la entrada de texto

Short description:

La prueba pasa, pero esta es una implementación rudimentaria. Queremos añadir flexibilidad permitiendo títulos personalizados y control de entrada. La prueba falla inicialmente, pero la actualizamos y la prueba pasa. Hemos añadido dos atributos más para la entrada de texto.

Nada más. Y la prueba pasa. Pero esta es una implementación muy rudimentaria. Está muy codificado, así que queremos darle algo de flexibilidad. Si queremos darle flexibilidad, y mientras actualizamos la prueba, también le daremos la capacidad de controlar los valores que estamos poniendo allí. Por lo tanto, el título, es útil que las personas puedan reutilizar la molécula, así que lo tendremos como un título personalizado. Y tendremos el control de la entrada. Bien. La prueba falla, porque no hay nada allí. Bien. Pongámoslo allí. Lo ponemos allí, está allí, la prueba pasa, estamos bien. Podemos continuar. Así que acabamos de añadir dos atributos más para la entrada de texto.

7. Construyendo un formulario con Desarrollo Guiado por Pruebas

Short description:

Con el desarrollo guiado por pruebas, puedes hacer lo necesario para que tu caso de uso pase. Tenemos moléculas. Vamos a tener un formulario. Vamos a escribir una prueba para un formulario en el que podamos pedir un nombre, podemos pedir un apellido y, como es un formulario, tendremos un botón para enviar la información. La prueba no podrá distinguir entre la molécula de entrada de texto y la segunda molécula de entrada de texto. Pero sabemos que hay dos de ellas, así que podemos hacer que funcione. Si por casualidad en el país en el que estás implementando el formulario, las personas suelen usar el nombre antes y el apellido antes y el nombre después, tu prueba fallará. El contenido del formulario, la forma en que se construye, aún funciona.

Pero como sabes, hay muchas cosas que se pueden introducir en una entrada. ¿Queremos construirlos todos? ¿Queremos empezar, no sé, con cada uno de ellos? No. No es necesario hacerlo. Con el desarrollo guiado por pruebas, puedes hacer lo necesario para que tu caso de uso pase. No más, no menos.

Tenemos moléculas. La entrada de texto. Así que, empecemos a juntar algunas cosas y veamos cómo podemos avanzar con el formulario. Vamos a tener un formulario. Vamos a escribir una prueba para un formulario en el que podamos pedir un nombre, podemos pedir un apellido y, como es un formulario, tendremos un botón para enviar la información. Cuando ejecutamos la prueba o cuando escribimos suficiente código de producción para que pase, esto parece decente. Tenemos dos moléculas. Una dice primero, otra dice último. Ahí está el botón. Bien. Sigamos adelante.

No sigamos adelante porque cada una de las entradas de texto va a renderizar un párrafo. Por lo tanto, la prueba no podrá distinguir entre la molécula de entrada de texto y la segunda molécula de entrada de texto. Esto es un poco molesto. Pero sabemos que hay dos de ellas, así que podemos hacer que funcione. Podemos decir que es un array. El primer elemento del array es el nombre. El segundo elemento del array es el apellido. Así que está bien. Está bien. Lo tenemos. Lo tenemos totalmente. Sin embargo, si por casualidad en el país en el que estás implementando el formulario, las personas suelen usar el nombre antes y el apellido antes y el nombre después, te sentirás un poco decepcionado. Tu prueba fallará. El contenido del formulario, la forma en que se construye, aún funciona.

8. Cambiando el Enfoque de las Pruebas

Short description:

Hagamos un cambio en la forma en que realizamos nuestras pruebas. Hagamos que nuestras pruebas se asemejen a la forma en que se utiliza el software. Al hacerlo, nos dará más confianza en la forma en que el software, en las pruebas que estamos realizando. Esta no es mi cita, es la cita de Ken Seedot para la biblioteca de pruebas.

No debería haber fallado. Entonces, ¿cómo podríamos solucionar esto? Bien. Probablemente podamos, si somos lo suficientemente hábiles, ir al formulario. Podemos intentar encontrar los elementos. Haremos clic derecho, inspeccionar. Buscaremos, ¿qué diablos es eso? Bien, tengo el ID, así que puedo ir y ajustar el código, y eso es todo, y tengo la prueba y todo está bien. Por favor, ten paciencia, está ocurriendo de nuevo. Solo nosotros, los nerds, hacemos esto. Los usuarios no hacen esto. Los usuarios buscarán algo. Los usuarios buscarán el texto que está escrito en la página que se muestra frente a ellos. Entonces, hagamos un cambio en la forma en que realizamos nuestras pruebas. Hagamos que nuestras pruebas se asemejen a la forma en que se utiliza el software. Al hacerlo, nos dará más confianza en la forma en que el software, en las pruebas que estamos realizando. Esta no es mi cita, es la cita de Ken Seedot para la biblioteca de testing.

9. Mejorando la Accesibilidad del Formulario y Refactorizando

Short description:

A partir de ahora, todo el desarrollo de pruebas seguirá la biblioteca de pruebas. Agregaremos etiquetas a los elementos del formulario para proporcionar información y mejorar la accesibilidad. Actualizaremos la molécula de entrada de texto para adaptar las etiquetas y garantizar la accesibilidad. La biblioteca de pruebas nos ayuda a identificar y solucionar cualquier problema con nuestras pruebas. Ahora podemos refactorizar y ampliar el código para incluir más campos de datos personales en el formulario.

A partir de ahora, todo el desarrollo de pruebas seguirá la biblioteca de pruebas. ¿Cómo se traduce esto en la prueba que tenemos? En lugar de tener solo el P, comencemos con el texto de la etiqueta. Tendremos una etiqueta para el apellido, tendremos una etiqueta para el nombre. También daremos una noticia, la ventaja de que el botón sea un elemento específico de HTML, y lo haremos clic, y eso es prácticamente todo.

Una pequeña nota sobre las etiquetas. La gente tiende a burlarse de mí porque pongo etiquetas en todo lo que hago. ¿Por qué es eso? Porque es un pequeño trozo de papel que se adjunta a un objeto y proporciona información sobre él. Sirve para computadoras, sirve para cables, sirve para cualquier cosa. En particular, para el desarrollo web, una etiqueta en un elemento de HTML representará una leyenda para un elemento que está en el documento. Por lo tanto, podrás acceder a él. Podrás alcanzarlo dentro de tu DOM.

Entonces, comencemos a escribir en los formularios que tenemos. Al hacerlo, podemos aumentar la complejidad de la prueba que acabamos de construir. También podremos darle el significado semántico de tener un formulario porque antes no tenía un formulario, solo tenía elementos dispersos en el documento. Así que tengamos un formulario dentro del documento. Tengamos el nombre, hagamos clic en él, escribamos cosas en él, usemos y simulemos las interacciones que el usuario hará con la página.

Pero esto nos plantea un problema, que es la molécula de entrada de texto, la molécula de entrada de texto no estaba preparada para recibir etiquetas, no estaba preparada para recibir más información que la que ya le dimos. Así que tendremos que volver, actualizar la molécula de entrada de texto y siempre teniendo en cuenta la accesibilidad. Por lo tanto, todas las consultas que estás haciendo, todas las pruebas que estás escribiendo, las estás haciendo pensando en cómo podré acceder a esto, cómo podré alcanzarlo? La biblioteca de pruebas es muy útil cuando se trata de decirnos qué está mal en nuestras pruebas. Así que simplemente arreglémoslo. Nada más, nada menos. Lo arreglamos. Parece feliz y satisfecho con eso. Y todas las pruebas pasan. Por lo tanto, pudimos no solo refactorizar, sino también ampliar el código que ya teníamos. Es bueno. Ya tenemos ese formulario con el nombre y apellido y luego el botón. Pero si recuerdas del formulario, solicitará más información sobre datos personales. Así que tal vez sea hora de refactorizar. Debería estar bien.

10. Creando el Organismo de Detalles Personales

Short description:

Creemos el organismo de detalles personales. Ejecuta las pruebas, refactoriza el código y mejora la accesibilidad. El desarrollo guiado por pruebas te brinda seguridad al desarrollar tu aplicación. Una vez que lo hayas unido todo, puedes construir, empaquetar y enviar. Tendrás confianza en el código que estás construyendo.

Creemos el organismo de detalles personales. Y mientras lo hacemos, démosle aún más significado. Digamos que es el nombre, el apellido y el correo electrónico. Esta es información personal. Todos estos campos de entrada se pueden agrupar dentro de un conjunto de campos. Se les puede dar contexto semántico. Se pueden poner en la misma bolsa para que puedas acceder a ellos de manera fácil.

Ejecuta las pruebas. Luego refactoriza el código. Ejecuta las pruebas y todo seguirá pasando. Así que has hecho una gran refactorización. Has logrado mejorar la accessibility de tu código. Y nada salió mal. Por lo tanto, el ciclo del desarrollo guiado por pruebas te brindará security mientras desarrollas tu aplicación, pensando primero en la accessibility.

Al final, eventualmente continuarás y desarrollarás el resto de los organismos y las moléculas. Desarrollarás la casilla de verificación, el campo de entrada, los botones de radio. Te encargarás de construir el menú desplegable, seleccionarlo, etc. Así que una vez que lo hayas unido todo, puedes subir un nivel, en lugar de escribir o codificar el HTML que estás haciendo, puedes construirlo, empaquetarlo, enviarlo y luego realizar pruebas de extremo a extremo en él. Siempre desde el punto de vista del usuario.

Si ejecutas la cosa con Cypress, ejecutas la prueba. Eventualmente se abrirá un navegador. Un navegador de tu elección. Puedes configurarlo. El formulario, si tienes más de una prueba, que suele ser un caso de uso para el usuario, se ejecutará. En cada escenario que tengas, podrás convertirlo en una prueba que se ejecutará cada vez que envíes tu código. Así que tendrás security en lo que estás haciendo. Tendrás confianza en que el código que estás construyendo lo estás haciendo usando accessibility primero y utilizando solo lo necesario para que funcione.

En conclusión, tienes accessibility. Tienes desarrollo guiado por pruebas. Es una combinación perfecta.

QnA

Manteniendo Etiquetas e IDs de Prueba en las Pruebas

Short description:

Porque puedes transformar tus historias de usuario en pruebas que impulsarán la implementación de sitios web, y también las pruebas en sí mismas, que son capaces de ser entendidas y apreciadas por todos nosotros. Así que vamos a pasar a las preguntas y respuestas. La primera pregunta es de un usuario anónimo. ¿Cómo mantendrías las etiquetas en la prueba? Hacerlo de forma dinámica eliminaría lo que el usuario busca. Tal vez las tengas en un archivo de constantes y las uses en el componente mismo, e incluso las importes en la prueba. Eso es lo que el usuario anónimo quiere decir. ¿Y qué piensas sobre el uso de IDs de prueba en lugar de etiquetas? ¿Como usuario, necesitas IDs de prueba? ¿O los necesitas como programador? Como usuario, diría que nunca necesitas ninguno. ¿Desarrollas código para programadores o desarrollas código para usuarios? Bueno, en realidad hago código para desarrolladores. Bueno, está bien. Pero en tu escenario, tienes razón.

Porque puedes transformar tus historias de usuario en pruebas que impulsarán la implementación de sitios web, y también las pruebas en sí mismas, que son capaces de ser entendidas y apreciadas por todos nosotros.

Así que eso fue todo. Muchas gracias.

Así que pasemos a las preguntas y respuestas. La primera pregunta es de un usuario anónimo. Muy bien. ¿Cómo mantendrías las etiquetas en la prueba? Hacerlo de forma dinámica eliminaría lo que el usuario busca, básicamente. Haciéndolo de forma dinámica. ¿Entonces ahora has codificado las cadenas, las etiquetas? Sí. Tal vez las tengas en un archivo de constantes y las uses en el componente mismo, e incluso las importes también en la prueba. Eso es lo que el usuario anónimo quiere decir. De acuerdo, ¿podría ser que el usuario anónimo se llame Metin? No. De acuerdo. Quién sabe. Eso parece un poco como si tuvieras traducciones y necesitaras poder usar algo que no esté codificado. En esos casos, debes abstraer lo que estás poniendo y lo que estás pasando a tu componente. Así que añade otro nivel de... No quiero decir complejidad, pero añade otro nivel de abstracción a tu código, y haz que sea el responsable de ocuparse de lo que cambia dinámicamente. Tal vez sobrescribe en la prueba, sobrescribe la importación, para que esté codificado y siempre sea lo mismo. Exactamente, está codificado, está simulado. Y eventualmente está simulado, por ejemplo, si es una traducción. Quieres asegurarte de que se haya llamado a la traducción. Algo simple, que te permita estar seguro de lo que estás haciendo. Solo necesita ser constante, ¿verdad? Por ejemplo, el primer nombre podría ser cadena uno, el apellido puede ser cadena dos. Por ejemplo. De acuerdo, gracias Anónimo. ¿Y qué piensas sobre el uso de IDs de prueba en lugar de etiquetas? Como usuario, ¿necesitas IDs de prueba? ¿O los necesitas como programador? Como usuario, diría que nunca necesitas ninguno. ¿Desarrollas código para programadores o desarrollas código para usuarios? Bueno, en realidad hago código para desarrolladores. Bueno, está bien. Pero en tu escenario, tienes razón.

Enfoque de Pruebas Centrado en el Usuario

Short description:

Siempre debes pensar en quién utilizará el software que estás desarrollando. Prueba tanto como sea posible como si el usuario estuviera utilizando tu aplicación. Escribe tus pruebas como si fueras un usuario. Enfócate en las etiquetas y los campos de entrada.

Siempre debes pensar en quiénes serán las personas que utilizarán el software que estás desarrollando. Si esa persona necesita un ID de prueba, entonces necesita un ID de prueba. Pero pregunta por qué la persona necesita el ID de prueba, no solo porque sí. Sí, y es como mostraste con el tweet de Kenzie Dodds, su cita fue simplemente, intenta probar tanto como sea posible como si el usuario estuviera utilizando tu aplicación e intenta escribir tus pruebas como si fueras un usuario. Y si eres un usuario, estás buscando esa etiqueta y haciendo clic en ella para que se enfoquen tus campos de entrada. Exactamente, exactamente.

Muy bien. Muy bien. Bueno, ese es el tiempo que tenemos, Rita. Así que muchas gracias. Gracias. ¿Alguna otra pregunta para Rita? Rita irá ahora al stand de los oradores y en Sli.do también puedes hacer tus preguntas. Todos, un gran aplauso para Rita.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.