Pruebas de integración encantadoras con Testcontainers

Rate this content
Bookmark

Los servicios Dockerizados son una excelente herramienta para crear entornos aislados y repetibles 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 su servicio en contenedores 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 siempre esté actualizada y sea consistente durante el desarrollo local y en los pipelines de CI.

Aprenderás todo lo necesario para comenzar a agregar pruebas de integración poderosas a tu base de código sin el dolor de cabeza de administrar dependencias de servicio externas manualmente!

Oleg Šelajev
Oleg Šelajev
21 min
03 Nov, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Las pruebas son cruciales para el desarrollo y la producción, con las pruebas de integración cada vez más populares. Testcontainers es una biblioteca que se integra con Docker para crear entornos de prueba confiables. Es flexible y se puede usar con varios marcos y bibliotecas de prueba. La configuración de IDE implica configurar el contenedor y conectarlo a la aplicación. Testcontainers se puede usar 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 súper importantes para el desarrollo y la producción. Las pruebas automatizadas son cruciales para la liberación de software. Las pruebas de integración se han vuelto más populares a medida que las aplicaciones dependen de las interacciones con sistemas de terceros. Proporcionan un conjunto de pruebas confiable que detecta problemas del mundo real.

Hola. Estás viendo TestJS Summit y estas son pruebas de integración encantadoras con Test Containers. Testing es muy importante. Más proyectos deberían probar las aplicaciones mejor 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 Test Containers.

Mi nombre es Alex Shoive y trabajo como una persona de Relaciones con Desarrolladores en Atomic Jar, una empresa creada... una startup creada por los mantenedores originales de Test Containers en Java 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 charlar sobre cualquier cosa. Test Containers, así que testing relacionado o simplemente ingeniería de software en general. Creo que sería muy, muy genial. Así que envíame, envíame un mensaje.

Testing es súper, súper importante porque se encuentra en los caminos críticos desde el desarrollo hasta la producción. Si no tenemos un buen conjunto de pruebas automatizadas, no podemos liberar cosas bien. Necesitamos tener pruebas automatizadas porque queremos asegurarnos de que siempre que tengamos algo que potencialmente queramos liberar, podemos pasar por nuestro pipeline sin cuellos de botella en ningún proceso manual. Esto es útil durante una práctica de desarrollo normal, ciclo de desarrollo, pero también es súper útil en caso de que haya problemas de seguridad o problemas de cadena de suministro de seguridad donde actualizas los paquetes de terceros, y luego necesitas liberar cosas porque podrían ser problemas 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 siempre. Pero si lo haces, puedes ejecutar tus pruebas automatizadas. Puedes liberar inmediatamente porque tienes confianza 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 testing y ejecutábamos un montón de unit tests y cubrían todos los escenarios posibles y teníamos una muy buena cobertura de pruebas, y aún así nos perdimos algunos problemas. Así que, recientemente, equipos independientes han estado saliendo a la luz sobre cómo están repensando la pirámide de testing y cómo ponen más y más énfasis en las pruebas de integración. Mientras tanto, tiene mucho sentido. Nuestras aplicaciones se han vuelto más pequeñas. Estamos escribiendo en su mayoría, y estamos hablando de las aplicaciones de backend aquí, estamos escribiendo principalmente microservices que hablan con otras APIs o hablan con varias tecnologías como bases de datos o intermediarios 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 más que en la lógica de negocio dentro de la aplicación particular, cómo transforma los data. Por lo tanto, tiene sentido tener menos pruebas de detalles de implementación, y usar la prueba de integración que ejecuta tu aplicación con el entorno inmediato, con todos los componentes necesarios para que tu aplicación funcione correctamente como lo haría en producción, pero en tu configuración de testing. Eso podría ser la mayor parte de nuestro conjunto de pruebas. Esa podría ser la prueba en la que confiamos y en la que nos apoyamos. Y todavía podemos tener pruebas de integración de extremo a extremo que se ejecutan en un entorno similar a la producción, donde todos los sistemas se activan al mismo tiempo. Y cuando verificamos los flujos de trabajo reales, como si fuera un entorno de producción, data de producción, o data similar, pero en un entorno mucho más grande. Así que para un conjunto de pruebas que ejecutas en todas partes, en tu máquina, en la máquina de tu colega, en tu CI, las pruebas de integración dan en el punto dulce entre la simplicidad de la configuración y también cuántos problemas con las tecnologías del mundo real pueden detectar. Por eso están ganando más y más popularidad.

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, haciendo tus pruebas más confiables. Test Containers utiliza Docker como el entorno para iniciar contenedores. Sin embargo, Docker a veces es inflexible para las pruebas de integración. Aquí es donde entra TestContainers, proporcionando acceso programático para crear y administrar contenedores para pruebas.

Esto nos lleva a Test containers. Test containers son bibliotecas en diferentes lenguajes, incluyendo la implementación de test getters' node que funciona para JavaScript y TypeScript. Se integran con Docker para crear entornos efímeros donde puedes ejecutar las dependencias de servicios de terceros que tu aplicación requiere. Puedes ejecutar las bases de datos, puedes ejecutar tu Kafka, puedes ejecutar tu Elasticsearch, puedes aprender tu local stack, si trabajas con tecnologías LWS.

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

Test containers ha sido recientemente nombrado en el Radar de Tecnología de ThoughtWorks. Fue puesto en la categoría Adulto, lo que significa técnicamente que debería haber una fuerte razón. Realmente deberías saber lo que estás haciendo, si no quieres usar Test containers. Test containers te permite crear un entorno confiable con la creación programática de esos containers ligeros para tus dependencias. Y hace tus pruebas más confiables, e intenta empujarte a hacer las cosas correctas con tus pruebas de integración, y por eso hay cada vez más proyectos, que están utilizando Test containers en diversas configuraciones y entornos.

Test containers utiliza Docker como el entorno donde inicia esos containers que tu aplicación quiere ejecutar. Y esto es genial porque Docker está casi universalmente disponible, funciona en todos los sistemas operativos populares, y sus desarrolladores entienden cómo funciona Docker, o cómo usar Docker desde el exterior. Así que esta es una gran opción para aprovechar un tiempo de ejecución para ejecutar esas dependencias para tu aplicación. Sin embargo, el aspecto y la sensación de Docker no son a veces lo suficientemente flexibles para tus pruebas de integración.

Docker es genial porque tiene todo el software del mundo que puede ser ejecutado en Docker. Hay registros donde puedes obtener todas las tecnologías que tu alma requiere. Te proporciona aislamiento de procesos. Te proporciona la capacidad de configurar tanto el contenedor como la aplicación dentro del contenedor. Te dan los límites de CPU y memoria. Todas esas cosas buenas, pero es un poco inflexible para las pruebas específicamente porque durante las pruebas, queremos poner nuestra aplicación en escenarios específicos donde algo podría salir mal. ¿Qué sucederá cuando la aplicación trabaje con una database y el esquema de data sea incorrecto? ¿O qué sucederá si mi aplicación no tiene una latencia larga hasta que llegue a Kafka? ¿O qué sucede cuando los números de clave de mi Redis están cerca del rango de enteros y están tratando de desbordarse? Todos los diferentes escenarios y todos rompen la configuración de alguna manera. Esta es la noción de pruebas. Esto es lo que las pruebas deberían hacer. Ponen tu aplicación bajo estrés y luego quieren averiguar si se comporta correctamente. Así que con Docker, una vez que rompes el entorno, es muy, muy difícil recrear el entorno. Y aquí es donde entra TestContainers.

TestContainers te da acceso programático para crear, administrar, ciclo de vida y limpiar los containers que quieres ejecutar. Te da una API para configurar tanto el contenedor, como exponer qué puertos quieres exponer desde el contenedor si estás trabajando con él a través de la red.

3. Introducción a Test Containers Continuación

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 de trabajo 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 de negocio. No se limita a Node.js y puede ser utilizado 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. Así que puedes configurar todo desde tus pruebas de aplicación, desde tu IDE. Y no necesitas, puedes, puedes hacer esto cualquier número de veces. Así que 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 Jest test containers, que simplifica el trabajo con Jest test, y test containers, donde puedes especificar declarativamente qué containers quieres, por ejemplo. Testcontainersnode, como las otras implementaciones de test containers, 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 test containers en tu aplicación. Y lo que hace, utiliza docker-node para hablar con el entorno docker, así que tu entorno docker no necesita ser ninguna implementación docker en particular. Por supuesto, funciona con Docker Desktop, pero también puede funcionar con cualquier otra implementación docker compatible. Así que, por ejemplo, si estás ejecutando Minikube, el ligero clúster de Kubernetes que expone la API de Docker, puedes usar eso para ejecutar tus pruebas basadas en test containers. O si estás usando un Docker remoto, tus test containers pueden hablar con eso. Y internamente en Atomic Jar, estamos construyendo la solución cloud, donde puedes obtener una VM bajo demanda y ejecutar tus pruebas de test containers contra eso. Así que es una configuración muy, muy flexible, y funciona realmente bien.

Una cosa que es muy importante aquí es que test containers se encarga de la limpieza de los containers. Sabemos que para pruebas de integración confiables, necesitas tener un entorno repetible, y para eso, siempre quieres limpiar después de la ejecución. Eso significa que si tus pruebas pasan, limpiamos los containers y los eliminamos. Si tus pruebas fallan, limpiamos los containers y los eliminamos. Si tu máquina funciona con un entorno Docker remoto y tu máquina se bloquea, como si Internet explotara, todavía limpiaremos los containers en el host Docker remoto. Eso significa que nunca estarás en una situación en la que tu prueba se conecte a la instancia de Kafka que iniciaste hace dos semanas y que por alguna razón está persistiendo en tu potente máquina CI. Y luego porque los problemas que surgen de eso son realmente, realmente difíciles de reproducir e increíblemente difíciles de debug y arreglar. Así que las bibliotecas de test containers intentan empujarte en la dirección correcta con las pruebas de contenedores de prueba para permitir la paralelización de las pruebas de manera agradable, para empujarte a usar la API correcta, para hacer la limpieza en todo momento. Y en general, es un enfoque muy, muy popular.

Además de ser una buena biblioteca por sí misma, test containers viene con un ecosystem de los modules donde las tecnologías populares tienen una pequeña implementación, pequeñas bibliotecas, pequeños modules, que especifican y codifican cómo ejecutar esa tecnología particular en tu code. Así que no tienes que averiguar qué necesitas hacer para ejecutar Cassandra en un contenedor Docker o Kafka en un contenedor Docker, pero puedes simplemente usar la API y especificar, dame un contenedor Kafka, dame un contenedor MongoDB, y obtendrás una instancia de eso inmediatamente para ti, lo cual es genial porque eso te permite concentrarte en la lógica de negocio real de tus tareas sin gastar tiempo en averiguar la infraestructura, porque eso es gestionado por task containers. Y no es sólo un proyecto de nodo, ¿verdad? Task containers es bueno las pruebas de integración son necesarias en cualquier ecosystem de cualquier lenguaje de programación. Así que lo que puedes hacer, puedes tener el enfoque similar en tu aplicación Java, en tus aplicaciones .NET, en tu aplicación Go, hay Python, hay task containers Rust. Así que es un enfoque de ingeniería muy, muy popular. Y ahora me gustaría mostrarte un poco cómo se siente tener tareas y cuáles son los bloques de construcción de la API que necesitas conocer para ser productivo con task containers.

4. Explorando IDE y Configuración Básica

Short description:

Vamos a explorar 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 task containers. Configuramos el contenedor especificando el nombre de la imagen Docker, exponiendo los puertos y copiando archivos. El contenedor puede ser ejecutado en cualquier lugar, y utilizamos la instancia del contenedor genérico para proporcionar información para que nuestra aplicación se conecte. Después de las pruebas, test containers limpia el contenedor. La prueba en sí misma coloca y recupera valores en Redis.

Vamos a explorar el IDE. Bien. Así que tengo un proyecto muy, muy simple aquí. No tiene ni siquiera la aplicación real. Solo quiero darles una idea de la API y hablar de lo que es importante desde el punto de vista de task containers.

Muy bien. Así que podemos declarar la dependencia como de costumbre para obtener ese paquete npm. Y aquí en nuestro archivo de prueba, lo que podemos hacer, podemos requerir task containers 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 task containers. Lo que necesitamos darle, necesitamos darle el nombre de la imagen Docker, que es en los casos actuales, Redis vamos a ejecutar con el contenedor 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 tu esquema de database enviándolo a tu contenedor. Y luego, por supuesto, tenemos los métodos para usar y configurar el ciclo de vida de nuestros containers de nuestra infraestructura que necesitamos para la prueba.

Así que aquí en esta prueba, estamos. Especificamos que queremos crear el contenedor antes de todas las pruebas. Así que este contenedor será compartido entre todas las pruebas. Actualmente, no tenemos muchas, pero creamos el contenedor y luego esto es lo interesante, el contenedor puede ser ejecutado en cualquier lugar. Puede estar ejecutándose en el host Docker remoto o en tu host local o en una VM en algún lugar. Cuando nos aseguramos de que nuestra aplicación sabe cómo hablar con la tecnología, con la database, o en este caso, Redis en ese contenedor, no codificamos ninguna configuración, pero usamos esa instancia de contenedor genérico para proporcionar información de dónde se está ejecutando para que podamos configurar nuestra aplicación correctamente. Así que aquí simplemente decimos, oh Redis, vas a hablar con Redis, el cliente Redis, lo siento. Vas a hablar con Redis por ese host, que obtenemos del contenedor y el puerto expuesto 6379 será mapeado al puerto aleatorio de alto nivel en el lado del host aquí. Digamos, obtenemos el puerto mapeado para ese valor, y luego nuestro cliente 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 test containers, cuando nuestras pruebas pasan, test containers lo limpiará por sí mismo. Pero esta es aún una buena práctica, si quieres desplegar miles de containers durante una suite de pruebas, tal vez deberías cuidar del ciclo de vida tú mismo y detenerlos. Así que simplemente no usan todos los recursos al mismo tiempo. Así que la prueba en sí misma es súper simple. Solo queremos poner los valores en Redis y obtener los valores en Redis. Y puedes ver que si ejecuto mi aplicación, entonces podemos ver que los containers están allí.

5. Ejecución de Pruebas e Importación de Módulos

Short description:

Al ejecutar las pruebas, los contenedores se activan 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 hago docker stats. Actualmente solo está el contenedor raíz, que es el contenedor testing que usa internamente para limpiar con fines de limpieza. Entonces, si solo hago. Configuración muy simple aquí. Así que volveré a ejecutar las pruebas y puedes ver que los containers se activarán por un segundo y luego también se ejecutarán.

Entonces, no ejecuto mi Docker localmente aquí. Utilizo la cloud de TestCenter, que está conectada a un clúster cercano. Ahí es donde se ejecutan mis containers Docker. Y luego, si quieres un ejemplo más grande de nuestra situación, entonces tengo uno diferente. Esta es una aplicación express real que utiliza MongoDB como almacenamiento. Permíteme solo la prueba muy simple. Veamos la prueba. Solo 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 data de vuelta. Entonces, esta es una prueba funcional de muy alto nivel.

Y la parte interesante aquí es que no construimos los containers nosotros mismos. No decimos cómo configurar MongoDB. Pero lo que estamos haciendo, solo estamos importando el módulo que podemos tener. Y si miras el... Si miras el repositorio, puedes ver que hay algunos modules que son para tecnologías bastante comunes. MySQL, Mongo, Kafka, Elasticsearch, Postgres que están ahí. Y no es una implementación tan grande. Entonces, si estás interesado en cualquier otra tecnología que quieras ejecutar, tal vez después de averiguarlo para tu entorno, considera contribuir con un módulo de vuelta. Eso sería un gran uso. Correcto. Entonces aquí usamos Mongo. Y puedes ver cómo funciona. Entonces, una forma de ser contenedor que ejecutamos.

6. Uso de Test Containers para Operaciones Complejas

Short description:

Los contenedores de prueba proporcionan una única forma de soportar 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 se inicie la base de datos, crear imágenes al vuelo y realizar diversas operaciones con Docker. Consulta la fuente en GitHub y únete a la comunidad de Slack para más discusiones.

Esperamos a eso. Eso va a notar es una magia. No solo paquete. Así que una única forma de soportarlo, por supuesto, para todas las operaciones complejas de larga duración como iniciar containers y esperar a la tecnología, el contenedor para comenzar. Y luego podemos configurar nuestro cliente MongoDB para usar la cadena de conexión de nuestro modelo. Ni siquiera necesitas saber qué es exactamente la cadena de conexión o cómo se ve. ¿Cuál es el formato de eso? Solo puedes ejecutarlo. Y esto es muy, muy genial.

Así que ahora después de eso, por supuesto, nos desconectamos y luego podemos ejecutar las pruebas. Y aquí ejecutamos más pruebas. Así que 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 será automáticamente extraída del Hub de Docker para soporte de Escritorio, los registros privados también, authentication, cualquier cosa que puedas extraer con Docker sería soportada. Y luego puedes simplemente ejecutarlo. Y luego después de que todo está dicho y hecho, los containers 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 yo preferiría ejecutarlo normalmente, ejecutarlo normalmente en mi máquina para mi ID, porque entonces pueden enviar puntos de interrupción y ejecutarlo a voluntad.

Así que solo una diapositiva más. Hay que puedes hacer las cosas complejas. Puedes construir topologías complejas con red. Puedes esperar a que la database en el contenedor se inicie. Puedes crear las imágenes al vuelo. Puedes extraer los registros y copiar archivos de ida y vuelta y ejecutar los comandos. Cualquier cosa que funcione con Docker funciona como test containers. Y creo que este es un enfoque realmente, realmente genial. Y eres bienvenido a consultar la fuente en GitHub. Y si tienes alguna pregunta o si quieres probar y hablar con la community, por favor únete a Slack en SlackTaskContainers.org para hablar con personas de ideas afines. Eso es todo. Muchas gracias por ver. Y si tienes alguna pregunta, estaré encantado de responderla. 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

Scaling Up with Remix and Micro Frontends
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.
Full Stack Components
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.
Making JavaScript on WebAssembly Fast
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.
Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
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.
Webpack in 5 Years?
JSNation 2022JSNation 2022
26 min
Webpack in 5 Years?
Top Content
What can we learn from the last 10 years for the next 5 years? Is there a future for Webpack? What do we need to do now?
Towards a Standard Library for JavaScript Runtimes
Node Congress 2022Node Congress 2022
34 min
Towards a Standard Library for JavaScript Runtimes
Top Content
You can check the slides for James' talk here.

Workshops on related topic

Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Hussien Khayoon
Kahvi Patel
2 authors
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.
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
Gleb Bahmutov
Gleb Bahmutov
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.
0 to Auth in an Hour Using NodeJS SDK
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Asaf Shen
Asaf Shen
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
Build a powerful DataGrid in few hours with Ag Grid
React Summit US 2023React Summit US 2023
96 min
Build a powerful DataGrid in few hours with Ag Grid
WorkshopFree
Mike Ryan
Mike Ryan
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
JavaScript-based full-text search with Orama everywhere
Node Congress 2023Node Congress 2023
49 min
JavaScript-based full-text search with Orama everywhere
Workshop
Michele Riva
Michele Riva
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.
Automated accessibility testing with jest-axe and Lighthouse CI
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Workshop
Bonnie Schulkin
Bonnie Schulkin
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.