Desglosando la complejidad en las pruebas

Rate this content
Bookmark

Aprende sobre las razones más comunes de la complejidad en las pruebas, cómo se manifiesta y cómo lidiar con esa complejidad para producir pruebas elegantes incluso para los sistemas más complejos.

15 min
03 Nov, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

La charla de hoy analiza la complejidad en las pruebas y cómo lidiar efectivamente con ella. El orador enfatiza la importancia de probar rutas críticas orientadas al usuario y modelar las pruebas desde la perspectiva del usuario. También resalta la importancia de crear una configuración de pruebas que permita que cualquier prueba se ejecute sin problemas y la testabilidad implícita de un sistema bien diseñado. La charla explora el impacto de elegir el entorno de pruebas adecuado, el papel de la configuración de pruebas en la mitigación de la complejidad y la importancia de la estructura y las expectativas de las pruebas. El orador proporciona consejos prácticos para abordar la complejidad en las pruebas, como mantener las pruebas planas, utilizar utilidades auxiliares y dividir las pruebas en archivos separados.

Available in English

1. Introducción a la Complejidad en las Pruebas

Short description:

Hoy, me gustaría hablar sobre la complejidad en las pruebas. La complejidad está destinada a ocurrir, pero es cómo elegimos lidiar con ella lo que importa. La complejidad en las pruebas puede provenir del sistema que se está probando o de las propias pruebas. Al enfrentar la complejidad del sistema, comience probando las rutas más críticas para el usuario. En cuanto a las pruebas, modele desde la perspectiva del usuario e invierta lo suficiente en la configuración de las pruebas.

Hola a todos. Mi nombre es Artem y soy ingeniero de software en Kotlinbox. Hoy me gustaría hablar sobre la complejidad en las pruebas, pero antes de comenzar, permítanme hacerles una pregunta simple. ¿Alguna vez han sentido que escribir una prueba para una funcionalidad requeriría más tiempo y esfuerzo que la propia funcionalidad? Bueno, al igual que yo, ustedes también lo han sentido. Entonces, es probable que estuvieran lidiando con una o tal vez varias formas en las que la complejidad puede manifestarse en su base de código.

Pero no deberían sentirse mal al respecto, porque no importa qué tan buenos ingenieros seamos y qué código increíble escribamos, la complejidad está destinada a ocurrir. Está bien. La complejidad en sí misma no es el problema. Lo que importa es cómo elegimos lidiar o no lidiar con cómo se manifiesta. Y aunque la complejidad puede ser un tema amplio, para el propósito de la charla de hoy, me gustaría referirme a ella como una cualidad o estado de ser difícil de escribir, entender y mantener una prueba. Y cuando se trata de la complejidad en las pruebas, se puede dividir en dos grupos principales. Es la complejidad que proviene del sistema que estamos probando, y esto puede ser cualquier código. Un componente de React, un controlador de ruta en el backend o una biblioteca de JavaScript. Y la complejidad que proviene de las pruebas que estamos escribiendo.

Así que comencemos desde el sistema. Y una de las formas más comunes en las que las personas se encuentran con la complejidad, proveniente del código que prueban, es que no saben qué probar. Estoy bastante seguro de que han estado en esta situación. Abren un archivo existente y parece que está haciendo todo lo posible en el universo, y no tienen ni idea de cómo abordar eso en las pruebas. Bueno, en realidad hay una gran regla que pueden seguir en estas situaciones. Es, cuando tengan dudas, comiencen probando las rutas más críticas para el usuario. Entonces, si están construyendo un producto de comercio electrónico, comenzar una estrategia de pruebas desde un flujo de registro o un flujo de pago tiene mucho sentido. Y si están desarrollando herramientas internas o bibliotecas, entonces comiencen desde esos flujos felices que los usuarios esperan, y eso los pondrá en el camino correcto.

Y luego, cuando sepan qué probar, el siguiente problema más grande, el próximo desafío, es cómo probar eso. Y creo que muy a menudo, cuando nos sentimos luchando con cómo abordar las pruebas, es porque podemos estar pasando por alto algún tipo de filosofía de pruebas. Y uno de los enfoques más útiles que he adoptado a lo largo de los años es probar como el usuario. Lo que significa es que cuando escriban una prueba, traten de modelarla desde la perspectiva del usuario. Entonces, las acciones de prueba que realicen emularán las acciones que ese usuario haría con su software. Y las afirmaciones que escriban realmente reflejarán las expectativas del usuario como resultado de sus acciones. Y luego, otra cosa que ayuda enormemente es cuando invierten lo suficiente en la configuración de las pruebas. Y siento que esto se pasa por alto con demasiada frecuencia y es una lástima, porque la configuración de las pruebas es quizás una de las fases más importantes que trata con la complejidad.

2. Complejidad en las Pruebas: Propósito y Testabilidad

Short description:

El objetivo de esta fase es crear un universo donde cualquier prueba pueda ejecutarse sin problemas. Cada prueba debe tener un propósito, que es describir la intención detrás del sistema. Probar la testabilidad de un sistema es una prueba implícita en sí misma. Los sistemas mal diseñados son difíciles de probar, mientras que los sistemas bien diseñados facilitan las pruebas.

Debido a que el objetivo de esta fase es crear este universo, esta caja, donde cualquier prueba puede ejecutarse, o cualquier prueba que desee escribir puede ejecutarse sin problemas. Y hablaré sobre la configuración de las pruebas un poco más adelante en la charla.

Bien, cuando sabes qué probar y cómo probar, es posible que te encuentres con otro problema que es escribir demasiadas pruebas. Y puede sonar como algo bueno al principio, pero en realidad no lo es porque cada prueba debe tener un propósito. Y a menudo parecemos olvidar el propósito detrás de las pruebas en general.

Y escribimos pruebas no para obtener cobertura de código o para que CI pase, aunque queremos eso. En realidad, escribimos pruebas por una sola razón. Y es que escribimos pruebas para describir la intención detrás del sistema. Piénsalo. Cada vez que escribes una pieza de lógica en tu código, tienes alguna intención. Quieres que ese código haga algo. Pero a menos que tengas una prueba automatizada para validar esa intención, no tienes ninguna prueba de que tu código funcione como se espera.

Entonces, la próxima vez que te enfrentes a una prueba, hazte una pregunta. ¿Lo que estoy testing está realmente relacionado con la intención detrás de este código? Porque si no lo está, es probable que puedas eliminar esta prueba y aún no perder valor en tu configuración de pruebas.

Y luego, la otra cosa es que, bueno, el mundo real es mucho más complejo que eso. Y a veces hay sistemas objetivamente complejos, ¿verdad? ¿O no? Porque una cosa que me encanta de las pruebas es que la testabilidad del sistema es una prueba implícita en sí misma.

Ahora, lo que esto significa es que cuando tienes sistemas mal diseñados, mal arquitecturados, como consecuencia, serán realmente difíciles de probar. Y lo contrario también es cierto. Permíteme darte algunos ejemplos de cómo se manifiesta esto.

Entonces, en esta función obtener usuario, obtenemos el usuario de la database. Pero también obtenemos todas las publicaciones del usuario. Y esto parece que no pertenece aquí. Porque ahora, para probar correctamente esta función, también necesitamos simular todo lo relacionado con las publicaciones. Y esto es un desafío. Lo que tal vez sería el enfoque adecuado aquí sería dividir esta función en dos y probarlas por separado, lo que sería mucho más fácil.

Otro ejemplo está relacionado con las dependencias que nuestro código introduce. Como este controlador de carrito de compras. Puedes ver que en el constructor, creamos una nueva conexión de database. Tal vez eso no sea una buena idea porque para probar este controlador ahora, necesitamos simular implícitamente este constructor de database de alguna manera. ¿Por qué no simplemente pasarlo como argumento al constructor, hacer inyección de dependencias y así permitirnos probar, por ejemplo, contra la database de prueba durante las pruebas, lo que haría toda esta experiencia mucho más fácil.

3. Abordando la Complejidad en las Pruebas del Sistema

Short description:

Sigue las mejores prácticas para escribir un código mejor y mejorar las pruebas. Establece una estrategia clara de pruebas y enfócate en los caminos críticos que enfrenta el usuario. Prueba como el usuario e invierte en la configuración de pruebas. Utiliza la testabilidad como una verificación implícita de la intención del código.

Pero mi objetivo aquí no es darte algunos consejos prácticos sobre cómo escribir un código mejor. Estoy bastante seguro de que ya lo sabes. Solo estoy tratando de animarte a seguir esas mejores prácticas. Porque cuanto mejor código escribas, mejores serán las pruebas para ese código. Así que las mejores prácticas importan.

Entonces, para resumir. ¿Cómo abordamos la complejidad que proviene del sistema? En primer lugar, establecemos una estrategia clara de pruebas. Y cuando tengamos dudas, probamos los caminos más críticos que enfrenta el usuario. Luego adoptamos alguna filosofía, por ejemplo, como probar como el usuario, lo cual realmente nos ayuda a modelar nuestras pruebas de manera más fácil y sabemos cómo abordar cualquier lógica que probemos. Necesitamos invertir en la configuración de pruebas porque es una de las partes más importantes de la configuración que nos permite escribir cualquier prueba que necesitemos. Y, por supuesto, podemos utilizar la testabilidad como una especie de verificación implícita para ayudarnos a ver que el código que estamos escribiendo sigue siendo fiel a la intención que tenemos para ese código.

4. Introducción a la Complejidad en las Pruebas

Short description:

A menudo introducimos complejidad en las pruebas nosotros mismos al elegir el entorno de pruebas incorrecto. Es importante seleccionar el entorno de pruebas adecuado que se alinee con el tiempo de ejecución previsto del código. Para las páginas de Next.js, automatiza las pruebas en un navegador, mientras que para las funciones simples de JavaScript, un marco de pruebas basado en Node.js sería suficiente.

Bien, ahora hablemos de la complejidad en las pruebas. Y una cosa que a menudo viene a la mente es que nosotros mismos introducimos esa complejidad. Por ejemplo, al elegir el entorno de pruebas incorrecto. Imagina que estás probando una página de Next.js, pero decides hacerlo en GSDOM. Bueno, vas a tener un mal momento porque ese entorno no está diseñado para probar páginas completas. Lo mismo ocurre si decides probar una función simple de JavaScript y generas una instancia completa de Chromium para hacerlo. Seguro, eso funcionaría, pero ¿es realmente el enfoque correcto? Y para resolver esto es muy sencillo. Elige el entorno de pruebas adecuado, y a menudo es el entorno en el que se destina a ejecutar tu código. Entonces, si es una página de Next.js, simplemente lánzala en un navegador y automatiza las pruebas allí. Si es una función simple de JavaScript, tal vez un marco de pruebas basado en Node.js sería suficiente para probarla de manera eficiente.

5. Configuración de Pruebas y Afirmaciones

Short description:

La configuración de pruebas es crucial para mitigar la complejidad. Crea un entorno donde cualquier prueba puede ejecutarse y maneja los efectos secundarios y las abstracciones de código comunes. Aborda la complejidad en la fase de configuración y utiliza funciones auxiliares para reducir el desorden visual. Evita la complejidad en las afirmaciones. Mantén la configuración de pruebas simple y responde a la complejidad con granularidad. Exagerar las afirmaciones puede llevar a la complejidad y la repetitividad.

De acuerdo, ahora, lo otro, y tal vez una de las cosas más cruciales en toda la sección de pruebas, es la configuración de pruebas. Y con qué frecuencia nos falta. Lo mencioné brevemente antes, así que profundicemos más aquí. La idea detrás de la configuración de pruebas es crear un entorno donde cualquier prueba que necesites pueda ejecutarse. Por eso esta fase debería hacer la mayor parte del trabajo pesado en términos de mitigación de la complejidad.

Entonces, aquí es donde se realiza la simulación de solicitudes HTTP, donde se crean bases de datos de prueba o se simula la conexión a bases de datos y se abordan cualquier tipo de efecto secundario que tu código comúnmente introduce. Por eso es crucial utilizar también las fases de configuración y acción. Permíteme mostrarte cómo hacerlo con un ejemplo. Cuando se trata de mitigar la complejidad, realmente quieres hacer la mayor parte en la fase de configuración, como mencioné. Una de las razones es porque lo haces una vez y tienes este entorno donde puedes ejecutar cualquier prueba, lo cual es genial. Pero incluso después de eso, seguirás teniendo cierta complejidad ocasional proveniente de las acciones de prueba que realizas, porque a menudo hay cierta lógica, ciertas abstracciones que hacemos en las pruebas, y simplemente puedes moverlas a funciones auxiliares y utilidades y reducir el desorden visual, pero también la complejidad de las pruebas en general. Y definitivamente nunca quieres abordar la complejidad en el nivel de las afirmaciones. Y te mostraré un ejemplo de por qué en un momento.

Pero lo más importante, mantenlo simple. Una vez tuve el placer de revisar una solicitud de extracción que tenía como objetivo mejorar la configuración de pruebas. Y aunque era genial, me avergüenza admitir que me llevó alrededor de 25-30 minutos entender qué hacía la configuración de pruebas para una sola prueba. Media hora, pero ni siquiera estaba cerca de entender qué hace la prueba, qué hace el código detrás de la prueba. No, solo la configuración. Y es realmente importante tener esto en cuenta al abordar la complejidad. Realmente no deberías responder a la complejidad con más complejidad porque las matemáticas siguen siendo válidas y uno más uno puede ser igual a dos complejidades. En cambio, quieres responder a la complejidad con granularidad. Entonces, funciones pequeñas con un propósito único que en total contribuyen a crear la configuración de pruebas que necesitas.

De acuerdo, ahora hablemos de las afirmaciones. Creo que, en aras de reducir la complejidad y la repetitividad, a veces tendemos a exagerar. Y aquí tienes un ejemplo. Esta es una afirmación de un bloque de prueba. Siempre que leo cualquier prueba, en realidad comienzo desde estas líneas de expectativa porque son las más útiles para mí. En esta prueba, esperamos que el contenido del archivo sea igual a una cadena. Es bastante sencillo. Pero no es lo que hace la prueba. Porque si miramos por encima de esta línea de expectativa, vemos que hay un bucle for.

6. Complejidad en la Estructura de Pruebas y Expectativas

Short description:

Probando que cada archivo de un seguidor tenga el mismo contenido, probando todos los seguidores y sus archivos para que sean iguales a una cadena específica, abstrayendo la complejidad, mejorando la línea de expectativa, enfocándose en la igualdad y la importancia de la estructura de pruebas.

Entonces, en realidad estamos probando que cada archivo de un seguidor tenga el mismo contenido. Y aún así, eso no es suficiente porque hay otro bucle arriba. Y en realidad estamos probando todos los seguidores y todos sus archivos para que sean iguales a una cadena específica. Solo nota cuántas cosas necesitamos calcular en nuestra cabeza para entender lo que hace la única línea de expectativa.

Entonces, parece que estamos abstrayendo la complejidad, pero en realidad solo estamos agregando más complejidad a nuestras mentes para abordarla. Así que creo que un bloque de prueba es el peor lugar para volverse inteligente. Y déjame mostrarte cómo podemos rehacer esta línea de expectativa para que sea mucho mejor. Entonces, esta es la misma afirmación de antes, pero ahora se lee en una sola línea. Esperamos que todos los contenidos de los archivos sean iguales a una cadena. Eso es todo. No hay contexto adicional adjunto. Y si necesitamos saber de dónde provienen los contenidos de los archivos, simplemente podemos ir a la línea que los obtiene, y podemos ver, hey, usa una función de utilidad. Así que abstraemos esa lógica porque en realidad, esta prueba no se preocupa por cómo extraer esos contenidos. Solo se preocupa por la igualdad.

Y luego otro punto se relaciona con la estructura de las pruebas. Y déjame contarte una historia. Una vez estaba trabajando en un proyecto realmente grande, y tenía muchas pruebas. Y una de las pruebas tenía 4,000 líneas de código. Y como suele suceder, algo salió mal. Hubo un problema y la integración continua comenzó a fallar. Así que me metí en esto e intenté averiguar qué estaba pasando. Y vi que esta prueba estaba fallando. Esta afirmación estaba fallando. Y pasé un par de minutos, y media hora, luego una hora, y simplemente no tenía sentido para mí. Porque, bueno, era como decir espero que 1 sea igual a 1, y era falso. No tenía sentido. Pero finalmente descubrí que un par de miles de líneas por encima de esa afirmación fallida, antes de OBLOCK, estaba mutando completamente el resultado de todo el sistema, y no estaba muy contento al respecto. Pero me enseñó una regla importante. Es que deberíamos intentar escribir pruebas que aún tengan sentido a las 3 a.m. Porque, imagina, es la mitad de la noche y el deber del paginador te despierta y la producción está fallando.

7. Lidiando con la Complejidad en las Pruebas

Short description:

Para evitar la frustración de depurar pruebas complejas, manténlas planas y elimina bloques describe innecesarios. Utiliza utilidades auxiliares para abstraer la lógica común, como completar un formulario de inicio de sesión. Divide las pruebas en archivos separados para mejorar la legibilidad y mantenibilidad. Utiliza adecuadamente las fases de prueba y reduce la repetición. Mantén la estructura de las pruebas plana y utiliza afirmaciones explícitas y simples. Divide las características complejas en el nivel del sistema de archivos para una mejor descubribilidad y mantenimiento.

Entonces, abres tu computadora portátil y lo primero que haces es ir a la prueba, que esperemos que esté allí, y tratas de averiguar qué está fallando y cuál es la intención, cómo se supone que debe funcionar. Pero si tienes muchas afirmaciones inteligentes que calcular en tu cabeza, si tienes una configuración de prueba complicada, si tienes este resultado mutable del sistema, vas a tener un momento muy difícil depurando todo eso. Así que terminarás frustrado, cerrarás tu computadora portátil y te irás a la cama, y esta será una experiencia horrible que podrías haber evitado.

Y puedes evitarlo manteniendo tus pruebas planas. Aquí tienes un ejemplo para ti. Esta es una prueba típica, así que tenemos un bloque describe que envuelve toda la característica, prepara un entorno antes de todas las pruebas, luego tiene una subcaracterística, por ejemplo, y tiene su propia configuración, y finalmente, la prueba. Incluso en este ejemplo simple, nota cuántas cosas necesitamos tener en cuenta solo para entender lo que necesita esta única prueba. Entonces, ¿por qué no ponerlo directamente en la prueba y eliminar por completo los bloques describe? Y te entiendo, al principio puede ser bastante confuso y repetitivo, pero con el tiempo, llegarás a amarlo, porque los beneficios que esto brinda son increíbles. Es declarativo, es explícito y comprendes lo que cada prueba necesita de la prueba, al leer la prueba. Y luego, por supuesto, puedes crear y reutilizar utilidades de prueba para abstraer la lógica comúnmente utilizada. Por ejemplo, si en esta prueba completamos un formulario de inicio de sesión y hacemos esto muy a menudo para probar la función de inicio de sesión, bueno, ¿por qué no abstraerlo en una utilidad auxiliar y llamarlo iniciar sesión? Y nota cómo esto se lee mucho mejor de inmediato, se lee como la intención, queremos iniciar sesión con estas credenciales. No importa cuáles sean los selectores de formulario, cuáles son las ideas y las clases, no importa, la intención es iniciar sesión y luego hacer algunas expectativas.

Y, por supuesto, una de las características o enfoques más pasados por alto es que puedes dividir las pruebas, no tienes que meter todas las pruebas en un solo archivo de prueba. Entonces, si tienes una característica complicada como esta de inicio de sesión y tiene diferentes proveedores como correo electrónico y GitHub, bueno, ponlos en archivos de prueba separados y te dará una gran legibilidad y descubribilidad sin costo alguno. Y luego, cuando necesites agregar más lógica y más pruebas, simplemente agrega nuevos archivos de prueba y eso es todo. Lo mismo ocurre cuando se eliminan características, porque al igual que un buen código, una buena prueba es aquella que se puede eliminar fácilmente. Es la prueba que no introduce muchas dependencias implícitas y todo tipo de magia en la configuración, lo que hace que sea muy difícil de eliminar.

Entonces, para resumir, al abordar la complejidad en las pruebas, es muy importante utilizar adecuadamente las fases de prueba y realizar la mayor parte del trabajo pesado en la fase de configuración. Y luego, por supuesto, reducir la repetición en la fase de acción. Es realmente crucial expresar las intenciones utilizando funciones auxiliares como la función de inicio de sesión que acabo de mostrarte para ayudar a que tu prueba se lea como una especificación en lugar de un montón de detalles de implementación. Es realmente bueno mantener la estructura de las pruebas plana, por lo que quizás poner todo lo que una sola prueba necesita en un solo bloque de prueba y, por supuesto, utilizar afirmaciones explícitas y simples para que no tengas que calcular muchas cosas en tu cabeza para entender lo que hace la prueba. Y cuando se trata de características complejas, también puedes dividirlas en el nivel del sistema de archivos y obtener esta gran capacidad de descubrimiento y gran mantenimiento a medida que se desarrolla tu producto. Por supuesto, hay mucho más sobre la complejidad, pero eso es todo lo que tengo por hoy, así que asegúrate de seguirme en Twitter si te gustó esta charla y comparte conmigo algunas de tus experiencias sobre cómo lidiaste con la complejidad en las pruebas en el pasado. Espero que disfrutes esto y que tengas un buen día.

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

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
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.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

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
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
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.