Pruebas de Integración Deliciosas con Testcontainers

Rate this content
Bookmark

Los servicios en contenedores de Docker son una excelente herramienta para crear entornos repetibles y aislados, ideales para pruebas de integración. En esta sesión, veremos las bibliotecas de Testcontainers que proporcionan una API flexible e intuitiva para controlar programáticamente el ciclo de vida de las dependencias de sus servicios en contenedores de Docker. Ejecutar bases de datos, Kafka, Elasticsearch e incluso tecnologías en la nube, directamente desde su código de prueba, asegura que la configuración del entorno esté siempre actualizada y consistente durante el desarrollo local y en los pipelines de CI.

¡Aprenderás todo lo necesario para comenzar a agregar potentes pruebas de integración a tu código sin la molestia de gestionar manualmente las dependencias de servicios externos!

21 min
03 Nov, 2022

Video Summary and Transcription

Las pruebas son cruciales para el desarrollo y la producción, y las pruebas de integración se están volviendo más populares. Testcontainers es una biblioteca que se integra con Docker para crear entornos de prueba confiables. Es flexible y se puede utilizar con varios frameworks y bibliotecas de pruebas. La configuración del IDE implica configurar el contenedor y conectarlo a la aplicación. Testcontainers se puede utilizar para operaciones complejas y permite ejecutar pruebas con dependencias reales.

Available in English

1. Introducción a las pruebas de integración

Short description:

Las pruebas son muy importantes para el desarrollo y la producción. Las pruebas automatizadas son cruciales para lanzar software. Las pruebas de integración se han vuelto más populares a medida que las aplicaciones dependen de interacciones con sistemas de terceros. Proporcionan un conjunto de pruebas confiable que detecta problemas del mundo real.

Hola. Estás viendo TestJS Summit y esto es una maravillosa prueba de integración con containers de prueba. Las pruebas son muy importantes. Más proyectos deberían probar mejor las aplicaciones y espero que después de esta breve sesión aprendas cómo puedes hacer pruebas de integración que te gusten usando las bibliotecas de prueba Containers.

Mi nombre es Alex Shoive y trabajo como persona de Relaciones con el Desarrollador en Atomic Jar, una empresa creada... una startup creada por los mantenedores de Java de Test Containers y ahora tenemos más personas de diferentes ecosistemas de lenguajes que nos ayudan a trabajar en Test Containers. Si tienes alguna pregunta, puedes encontrarme en línea. Estaré encantado de hablar sobre cualquier cosa. Test Containers, así que relacionado con las pruebas o simplemente ingeniería de software en general. Creo que sería muy, muy genial. Así que escríbeme, escríbeme una línea.

Las pruebas son súper, súper importantes porque se encuentran en los caminos críticos desde el desarrollo hasta la producción. Si no tenemos un buen conjunto de pruebas automatizadas, no podemos lanzar las cosas correctamente. Necesitamos tener pruebas automatizadas porque queremos asegurarnos de que cada vez que tengamos algo que potencialmente queremos lanzar, podamos pasar por nuestro pipeline sin obstáculos en ningún proceso manual. Esto es útil durante una práctica de desarrollo normal, un ciclo de desarrollo, pero también es súper útil en caso de que haya problemas de seguridad o problemas de seguridad de la cadena de suministro donde actualizas los paquetes de terceros y luego necesitas lanzar cosas porque podrían ser correcciones de seguridad y vulnerabilidades, pero si no tienes buenos conjuntos de pruebas en los que confíes, entonces este es un proceso manual y estás tan expuesto como sin pruebas. Pero si lo tienes, puedes ejecutar tus pruebas automatizadas. Puedes lanzar inmediatamente porque confías en tus pruebas. Esto es muy, muy importante, y últimamente, la forma en que vemos qué tipos de pruebas queremos ejecutar ha cambiado.

En el pasado, teníamos la pirámide de pruebas y ejecutábamos un montón de pruebas unitarias y cubrían todos los escenarios posibles y teníamos una muy buena cobertura de pruebas, y aún así nos perdimos algunos problemas. Entonces, recientemente, los equipos independientes han estado saliendo con cómo están repensando la pirámide de pruebas y cómo están poniendo más énfasis en las pruebas de integración. Mientras tanto, tiene mucho sentido. Nuestras aplicaciones se han vuelto más pequeñas. Principalmente estamos escribiendo, y estamos hablando de las aplicaciones backend aquí, estamos principalmente escribiendo microservicios que se comunican con otras API o con varias tecnologías como bases de datos o brokers de mensajes o tecnologías de Cloud, y el comportamiento de la aplicación está muy codificado en las interacciones con esos sistemas de terceros en lugar de la lógica de negocio dentro de la aplicación en particular, cómo transforma los datos. Por lo tanto, tiene sentido tener menos pruebas de detalles de implementación y utilizar las pruebas de integración que ejecutan tu aplicación con el entorno inmediato, con todos los componentes necesarios para que tu aplicación se ejecute correctamente como lo haría en producción, pero en tu entorno de pruebas. Eso podría ser la mayor parte de nuestro conjunto de pruebas. Eso podría ser la prueba en la que confiamos y en la que nos apoyamos. Y aún podemos tener pruebas de integración de extremo a extremo que se ejecutan en un entorno similar a producción, donde todos los sistemas se inician al mismo tiempo. Y cuando verificamos los flujos de trabajo reales, como si fuera un entorno de producción, datos de producción o datos similares, pero en un entorno mucho más grande. Entonces, para un conjunto de pruebas que se ejecutan en todas partes, en tu máquina, en la máquina de tu colega, en tu CI, las pruebas de integración alcanzan el punto óptimo entre la simplicidad de la configuración y también cuántos problemas con las tecnologías del mundo real pueden detectar. Es por eso que se están volviendo cada vez más populares.

2. Introducción a Test Containers

Short description:

Test Containers es una biblioteca que se integra con Docker para crear entornos efímeros para ejecutar dependencias de servicios de terceros. Te permite probar tu aplicación con dependencias reales, lo que hace que tus pruebas sean más confiables. Test Containers utiliza Docker como entorno para crear contenedores. Sin embargo, Docker a veces es inflexible para las pruebas de integración. Aquí es donde entra en juego TestContainers, proporcionando acceso programático para crear y gestionar contenedores para pruebas.

Esto nos lleva a las pruebas con contenedores. Test Containers es una biblioteca en diferentes lenguajes, incluyendo la implementación de test getters para JavaScript y TypeScript. Se integra con Docker para crear entornos efímeros donde puedes ejecutar las dependencias de servicios de terceros que tu aplicación requiere. Puedes ejecutar bases de datos, Kafka, Elasticsearch, tu stack local si trabajas con tecnologías LWS.

Puedes ejecutarlos en contenedores Docker y tu aplicación tiene el control total sobre el ciclo de vida de los mismos. Tus pruebas tienen el control total sobre la configuración de los contenedores. Así puedes probar tu aplicación con las dependencias reales y saber que funciona como se espera.

Test Containers ha sido mencionado recientemente en el ThoughtWorks Technology Radar. Ha sido clasificado en la categoría Adult, lo que significa que hay una fuerte razón para utilizarlo. Debes saber realmente lo que estás haciendo si no quieres usar Test Containers. Permite crear un entorno confiable con la creación programática de contenedores ligeros para tus dependencias. Esto hace que tus pruebas sean más confiables y te ayuda a hacer las cosas correctas con tus pruebas de integración. Por eso cada vez más proyectos están utilizando Test Containers en diferentes configuraciones y entornos.

Test Containers utiliza Docker como el entorno donde se ejecutan los contenedores que tu aplicación desea ejecutar. Esto es genial porque Docker está disponible prácticamente en todas partes, se ejecuta en todos los sistemas operativos populares y los desarrolladores entienden cómo funciona Docker o cómo usar Docker desde el exterior. Es una gran opción para aprovechar un tiempo de ejecución para ejecutar esas dependencias para tu aplicación. Sin embargo, la apariencia y la experiencia de usuario predeterminada de Docker a veces no es lo suficientemente flexible para las pruebas, especialmente porque durante las pruebas queremos poner nuestra aplicación en escenarios específicos donde algo podría salir mal. ¿Qué sucede cuando la aplicación funciona con una base de datos y el esquema de datos es incorrecto? ¿O qué sucede si mi aplicación no tiene una latencia larga hasta que llega a Kafka? ¿O qué sucede cuando mis claves de Redis están cerca del rango entero y están tratando de desbordarse? Todos estos escenarios diferentes rompen la configuración de alguna manera. Esa es la idea de las pruebas. Eso es lo que deben hacer las pruebas. Ponen tu aplicación bajo estrés y luego intentan averiguar si se comporta correctamente. Con Docker, una vez que rompes el entorno, es muy, muy difícil recrearlo. Y ahí es donde entra TestContainers.

TestContainers te brinda acceso programático para crear, gestionar, controlar el ciclo de vida y limpiar los contenedores que deseas ejecutar. Te proporciona una API para configurar tanto el contenedor, como exponer los puertos que deseas desde el contenedor si estás trabajando con él a través de la red.

3. Introducción a Test Containers Continuado

Short description:

Test Containers es un enfoque popular para las pruebas de integración que proporciona una configuración flexible. Se integra con varios marcos y bibliotecas de pruebas, incluyendo Jest. Test Containers se encarga de la limpieza de los contenedores, asegurando un entorno repetible. La biblioteca viene con módulos para ejecutar tecnologías populares en contenedores, permitiendo a los desarrolladores centrarse en la lógica del negocio. No se limita a Node.js y se puede utilizar en cualquier ecosistema de lenguaje de programación.

O qué archivos quieres copiar, o si quieres seguir programáticamente los registros del contenedor, y así sucesivamente. Por lo tanto, puedes configurarlo todo desde las pruebas de tu aplicación, desde tu IDE. Y no necesitas, puedes hacer esto cualquier número de veces. Entonces las pruebas traen su propio entorno al juego. Y también se integra con varios frameworks y bibliotecas de pruebas.

Por ejemplo, hay un módulo para las pruebas de Jest con contenedores, que simplifica el trabajo con las pruebas de Jest, y los contenedores de prueba, donde puedes especificar de manera declarativa qué contenedores quieres, por ejemplo. Testcontainersnode, al igual que las otras implementaciones de contenedores de prueba, es un proyecto de código abierto. Christian es un verdadero héroe de la implementación de testcontainersnode, el principal mantenedor actualmente. Hay un paquete npm, que es cómo obtienes los contenedores de prueba en tu aplicación. Y lo que hace, es usar docker-node para comunicarse con el entorno de Docker, por lo que tu entorno de Docker no necesita ser una implementación de Docker en particular. Por supuesto, funciona con Docker Desktop, pero también puede funcionar con cualquier otra implementación de Docker compatible. Por ejemplo, si estás utilizando Minikube, el clúster ligero de Kubernetes que expone la API de Docker, puedes usarlo para ejecutar tus pruebas basadas en contenedores de prueba. O si estás utilizando un Docker remoto, tus contenedores de prueba pueden comunicarse con él. Y internamente en Atomic Jar, estamos construyendo la solución en la nube, donde puedes obtener una máquina virtual bajo demanda y ejecutar tus pruebas de contenedores de prueba en ella. Por lo tanto, es una configuración muy, muy flexible y funciona muy bien.

Una cosa que es muy importante aquí es que los contenedores de prueba se encargan de la limpieza de los contenedores. Sabemos que para pruebas de integración confiables, necesitas tener un entorno repetible, y para eso, siempre quieres hacer la limpieza después de la ejecución. Eso significa que si tus pruebas pasan, limpiamos los contenedores y los eliminamos. Si tus pruebas fallan, limpiamos los contenedores y los eliminamos. Si tu máquina se ejecuta con un entorno de Docker remoto y tu máquina se bloquea, como si se cae Internet, aún limpiaremos los contenedores en el host de Docker remoto. Eso significa que nunca estarás en una situación en la que tus pruebas se conecten a la instancia de Kafka que iniciaste hace dos semanas y que sigue activa por alguna razón en tu potente máquina de CI. Y luego, porque los problemas que surgen a partir de eso son realmente, realmente difíciles de reproducir e increíblemente difíciles de depurar y solucionar. Por lo tanto, los contenedores de prueba intentan guiarte en la dirección correcta con las pruebas de contenedores de prueba para permitir la paralelización de las pruebas de manera adecuada, para guiarte en el uso de la API correcta, para realizar la limpieza en todo momento. Y en general, es un enfoque muy, muy popular.

Además de ser una buena biblioteca en sí misma, los contenedores de prueba vienen con un ecosistema de módulos donde las tecnologías populares tienen pequeñas implementaciones, pequeñas bibliotecas, pequeños módulos, que especifican y codifican cómo ejecutar esa tecnología en tu código. Por lo tanto, no tienes que averiguar qué necesitas hacer para ejecutar Cassandra en un contenedor de Docker o Kafka en un contenedor de Docker, sino que simplemente puedes usar la API y especificar, dame un contenedor de Kafka, dame un contenedor de MongoDB, y obtendrás una instancia de eso inmediatamente para ti, lo cual es genial porque eso te permite concentrarte en la lógica del negocio real de tus tareas sin perder tiempo en averiguar la infraestructura, porque eso es gestionado por los contenedores de prueba. Y no es solo un proyecto de Node, ¿verdad? Los contenedores de prueba son necesarios en cualquier ecosistema de cualquier lenguaje de programación. Por lo tanto, lo que puedes hacer, puedes tener un enfoque similar en tu aplicación Java, en tus aplicaciones .NET, en tu aplicación Go, hay Python, hay contenedores de prueba Rust. Por lo tanto, es un enfoque de ingeniería muy, muy popular. Y ahora me gustaría mostrarte un poco cómo se siente tener contenedores de prueba y cuáles son los componentes básicos de la API que necesitas conocer para ser productivo con los contenedores de prueba.

4. Explorando el IDE y la configuración básica

Short description:

Veamos el IDE. Podemos declarar la dependencia como de costumbre para obtener el paquete npm. El bloque de construcción básico es el contenedor genérico, que representa el contenedor gestionado por los contenedores de tareas. Configuramos el contenedor especificando el nombre de la imagen de Docker, exponiendo puertos y copiando archivos. El contenedor se puede ejecutar en cualquier lugar y utilizamos la instancia del contenedor genérico para proporcionar información a nuestra aplicación para conectarse. Después de las pruebas, los contenedores de prueba limpian el contenedor. La prueba en sí misma coloca y recupera valores en Redis.

Veamos el IDE. Correcto. Aquí tengo un proyecto muy, muy simple. Ni siquiera tiene la aplicación real. Solo quiero darte una idea de la API y hablar sobre lo importante desde el punto de vista de los contenedores de tareas.

Muy bien. Podemos declarar la dependencia como de costumbre para obtener ese paquete npm. Y aquí en nuestro archivo de prueba, lo que podemos hacer es requerir los contenedores de tareas y el bloque de construcción básico es el contenedor genérico. El contenedor genérico es una abstracción que representa el contenedor que podemos gestionar a través de los contenedores de tareas. Lo que necesitamos proporcionarle es el nombre de la imagen de Docker, que en este caso es Redis, que vamos a ejecutar con el contenedor de Redis, y luego hacemos la configuración. Podemos exponer los puertos. Podemos configurar qué archivos necesitamos copiar en el contenedor. Por ejemplo, esta es una buena manera de instanciar el esquema de tu base de datos enviándolo a tu contenedor. Y luego, por supuesto, tenemos los métodos para usar y configurar el ciclo de vida de nuestros contenedores, de nuestra infraestructura que necesitamos para la prueba.

Entonces aquí en esta prueba, estamos. Especificamos que queremos crear el contenedor antes de todas las pruebas. Por lo tanto, este contenedor se compartirá entre todas las pruebas. Actualmente, no tenemos muchas, pero creamos el contenedor y luego, esto es lo interesante, el contenedor se puede ejecutar en cualquier lugar. Puede ejecutarse en el host de Docker remoto, en tu host local o en una máquina virtual en algún lugar. Cuando nos aseguramos de que nuestra aplicación sepa cómo comunicarse con la tecnología, con la base de datos, o en este caso, Redis en ese contenedor, no configuramos ninguna configuración de forma rígida, sino que utilizamos esa instancia de contenedor genérico para proporcionar información sobre dónde se está ejecutando para que podamos configurar nuestra aplicación correctamente. Entonces aquí simplemente decimos, oh Redis, vas a comunicarte con Redis, el cliente de Redis, lo siento. Vas a comunicarte con Redis a través de ese host, que obtenemos del contenedor, y el puerto expuesto 6379 se asignará al puerto aleatorio de alto nivel en el lado del host aquí. Digamos, obten el puerto mapeado para ese valor, y luego nuestro cliente de Redis está listo para conectarse a Redis. Después de todo, limpiamos todo, pero no tenemos que hacerlo. Al menos no tenemos que limpiar el contenedor porque los contenedores de prueba, cuando nuestras pruebas pasan, los limpiarán por sí mismos. Pero esto sigue siendo una buena práctica, si quieres crear miles de contenedores durante un conjunto de pruebas, tal vez debas encargarte del ciclo de vida en sí y detenerlos. Así que no usen todos los recursos al mismo tiempo. Entonces la prueba en sí es muy simple. Solo queremos colocar los valores en Redis y obtener los valores en Redis. Y puedes ver que si ejecuto mi aplicación, podemos ver que los contenedores están ahí.

5. Ejecución de pruebas e importación de módulos

Short description:

Al ejecutar pruebas, los contenedores se inician y se ejecutan en la nube de TestCenter. Se proporciona un ejemplo de una aplicación Express que utiliza MongoDB como almacenamiento. Las pruebas utilizan SuperTest para pruebas funcionales de alto nivel, esperando solicitudes exitosas y recuperación de datos. En lugar de construir los contenedores nosotros mismos, importamos módulos para tecnologías comunes como MySQL, MongoDB, Kafka, Elasticsearch y Postgres. Se agradecen las contribuciones de módulos para otras tecnologías.

Entonces, si ejecuto docker stats. Actualmente solo hay el contenedor raíz, que es el contenedor de testing que se utiliza internamente para limpiar con fines de limpieza. Si simplemente hago. Configuración muy simple aquí. Ejecutaré las pruebas nuevamente y verás que los contenedores se iniciarán durante un segundo y luego se ejecutarán también.

Entonces, no ejecuto mi Docker localmente aquí. Utilizo la nube de TestCenter, que está conectada a un clúster cercano. Ahí es donde se ejecutan mis contenedores de Docker. Y si quieres un ejemplo más grande de nuestra situación, entonces tenemos uno diferente. Esta es una aplicación Express real que utiliza MongoDB como almacenamiento. Permíteme hacer la prueba muy simple. Veamos la prueba. Simplemente usamos SuperTest para enviar una solicitud, pruebas funcionales de alto nivel reales para nuestra aplicación. Y luego esperamos que esas solicitudes tengan éxito. Y luego esperamos los datos de vuelta. Así que esta es una prueba funcional de alto nivel muy simple.

Y la parte interesante aquí es que no construimos los contenedores nosotros mismos. No decimos cómo configurar MongoDB. Lo que estamos haciendo es simplemente importar el módulo que podemos tener. Y si miras el... Si miras el repositorio, verás que hay algunos módulos para tecnologías bastante comunes. MySQL, Mongo, Kafka, Elasticsearch, Postgres están ahí. Y no es una implementación tan grande. Así que si estás interesado en cualquier otra tecnología que quieras ejecutar, tal vez después de descubrirlo para tu entorno, considera contribuir con un módulo. Eso sería de gran utilidad. Aquí usamos Mongo. Y puedes ver cómo funciona. Así que una forma de ser el contenedor que ejecutamos.

6. Using Test Containers for Complex Operations

Short description:

Los contenedores de prueba proporcionan una forma única de admitir operaciones complejas de larga duración, como iniciar contenedores y esperar a que se inicien. Es un enfoque flexible y fácil de integrar que te permite ejecutar pruebas con dependencias reales. Puedes construir topologías complejas, esperar a que la base de datos se inicie, crear imágenes sobre la marcha y realizar diversas operaciones con Docker. Echa un vistazo al código fuente en GitHub y únete a la comunidad de Slack para más discusiones.

Esperamos eso. Eso va a ser mágico. No solo un paquete. Es una forma única de admitirlo, por supuesto, para todas las operaciones complejas de larga duración como iniciar contenedores y esperar a que la tecnología, el contenedor se inicie. Y luego podemos configurar nuestro cliente MongoDB para usar la cadena de conexión de nuestro modelo. Ni siquiera necesitas saber exactamente cuál es la cadena de conexión o cómo se ve. ¿Cuál es el formato de eso? Simplemente puedes ejecutarlo. Y esto es muy, muy genial.

Entonces, después de eso, por supuesto, nos desconectamos y luego podemos ejecutar las pruebas. Y aquí ejecutamos más pruebas. Entonces, si ejecuto NPM test aquí, puedes ver en segundo plano, si la imagen de Docker no está en la caché de mi demonio de Docker, entonces la imagen se descargará automáticamente desde Docker Hub para el soporte de escritorio, también se admiten registros privados, autenticación, cualquier cosa que puedas descargar con Docker sería compatible. Y luego puedes simplemente ejecutarlo. Y luego, después de que todo esté dicho y hecho, los contenedores se limpian y se eliminan junto con los volúmenes y todo eso. Así que es un enfoque muy, muy flexible. Es muy fácil de integrar en tus aplicaciones. También puedes empaquetar tu aplicación en un contenedor de Docker, pero preferiría ejecutarla normalmente, ejecutarla normalmente en mi máquina para mi IDE, porque luego puedo enviar puntos de interrupción y ejecutarlo a voluntad.

Así que solo una diapositiva más. Puedes hacer cosas complejas. Puedes construir topologías complejas con redes. Puedes esperar a que la base de datos en el contenedor se inicie. Puedes crear imágenes sobre la marcha. Puedes obtener los registros y copiar archivos de ida y vuelta y ejecutar comandos. Todo lo que funciona con Docker funciona como contenedores de prueba. Y creo que este es realmente un enfoque genial. Y te invitamos a ver el código fuente en GitHub. Y si tienes alguna pregunta o si quieres probar y hablar con la comunidad, únete a Slack en SlackTaskContainers.org para hablar con personas afines. Eso es todo. Muchas gracias por ver. Y si tienes alguna pregunta, estaré encantado de responder. Gracias.

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.
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 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 - 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.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
React Summit US 2023React Summit US 2023
96 min
Build a powerful DataGrid in few hours with Ag Grid
WorkshopFree
Does your React app need to efficiently display lots (and lots) of data in a grid? Do your users want to be able to search, sort, filter, and edit data? AG Grid is the best JavaScript grid in the world and is packed with features, highly performant, and extensible. In this workshop, you’ll learn how to get started with AG Grid, how we can enable sorting and filtering of data in the grid, cell rendering, and more. You will walk away from this free 3-hour workshop equipped with the knowledge for implementing AG Grid into your React application.
We all know that rolling our own grid solution is not easy, and let's be honest, is not something that we should be working on. We are focused on building a product and driving forward innovation. In this workshop, you'll see just how easy it is to get started with AG Grid.
Prerequisites: Basic React and JavaScript
Workshop level: Beginner
Node Congress 2023Node Congress 2023
49 min
JavaScript-based full-text search with Orama everywhere
Workshop
In this workshop, we will see how to adopt Orama, a powerful full-text search engine written entirely in JavaScript, to make search available wherever JavaScript runs. We will learn when, how, and why deploying it on a serverless function could be a great idea, and when it would be better to keep it directly on the browser. Forget APIs, complex configurations, etc: Orama will make it easy to integrate search on projects of any scale.
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Workshop
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.