a11y y TDD: Una Combinación Perfecta

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í.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.