Advertisement
  1. Code
  2. Go

Prueba de código intensivo de datos con Go, parte 3

Scroll to top
Read Time: 8 min
This post is part of a series called Testing Data-Intensive Code with Go.
Testing Data-Intensive Code With Go, Part 2
Testing Data-Intensive Code With Go, Part 4

Spanish (Español) translation by steven (you can also view the original English article)

Visión general

Esta es la tercera parte de cinco de una serie de tutoriales sobre cómo probar código con uso intensivo de datos con Go. En la segunda parte, cubrí las pruebas contra una capa de datos en memoria real basada en el popular SQLite. En este tutorial, repasaré las pruebas en una capa de datos local compleja que incluye una base de datos relacional y una caché de Redis.

Prueba contra una capa de datos local

Probar contra una capa de datos en memoria es increíble. Las pruebas son ultrarrápidas y tienes el control total. Pero a veces necesitas estar más cerca de la configuración real de tu capa de datos de producción. A continuación, se indican algunas posibles razones:

  • Utilizas detalles específicos de tu base de datos relacional que deseas probar.
  • Tu capa de datos consta de varios almacenes de datos que interactúan.
  • El código bajo prueba consta de varios procesos que acceden a la misma capa de datos.
  • Deseas preparar u observar tus datos de prueba utilizando herramientas estándar.
  • No deseas implementar una capa de datos en memoria dedicada si tu capa de datos está en proceso de cambio.
  • Solo deseas saber que estás probando con tu capa de datos real.
  • Necesitas probar con una gran cantidad de datos que no caben en la memoria.

Estoy seguro de que hay otras razones, pero puedes ver por qué el simple hecho de usar una capa de datos en memoria para las pruebas puede no ser suficiente en muchos casos.

Bien. Entonces queremos probar una capa de datos real. Pero aún queremos ser lo más ligeros y ágiles posible. Eso significa una capa de datos local. Estos son los beneficios:

  • No es necesario aprovisionar ni configurar nada en el centro de datos o la nube.
  • No hay necesidad de preocuparte de que nuestras pruebas corrompan los datos de producción por accidente.
  • No es necesario coordinarse con otros desarrolladores en un entorno de prueba compartido.
  • No hay lentitud en las llamadas de la red.
  • Control total sobre el contenido de la capa de datos, con la capacidad de comenzar desde cero en cualquier momento.

En este tutorial subiremos la apuesta. Implementaremos (muy parcialmente) una capa de datos híbrida que consta de una base de datos relacional MariaDB y un servidor Redis. Luego, usaremos Docker para crear una capa de datos local que podamos usar en nuestras pruebas.

Uso de Docker para evitar dolores de cabeza durante la instalación

Primero, necesitas Docker, por supuesto. Consulta la documentación si no estás familiarizado con Docker. El siguiente paso es obtener imágenes para nuestros almacenes de datos: MariaDB y Redis. Sin entrar en demasiados detalles, MariaDB es una gran base de datos relacional compatible con MySQL, y Redis es un gran almacén de valores clave en memoria (y mucho más).

Ahora que tenemos Docker instalado y tenemos las imágenes para MariaDB y Redis, podemos escribir un archivo docker-compose.yml, que usaremos para lanzar nuestros almacenes de datos. Llamemos a nuestro DB "songify".

Puedes iniciar tus almacenes de datos con el comando docker-compose up (similar a vagrant up). La salida debería verse así:

En este punto, tienes un servidor MariaDB completo que escucha en el puerto 3306 y un servidor Redis que escucha en el puerto 6379 (ambos son los puertos estándar).

La capa de datos híbridos

Aprovechemos estos poderosos almacenes de datos y actualicemos nuestra capa de datos a una capa de datos híbrida que almacena en caché las canciones por usuario en Redis. Cuando se llama a GetSongsByUser(), la capa de datos primero verificará si Redis ya almacena las canciones para el usuario. Si lo hace, simplemente devuelve las canciones de Redis, pero si no lo hace (falta de caché), buscará las canciones de MariaDB y completará el caché de Redis, por lo que estará listo para la próxima vez.

Aquí está la estructura y la definición del constructor. La estructura mantiene un identificador DB como antes y también un cliente redis. El constructor se conecta tanto a la base de datos relacional como a Redis. Crea el esquema y elimina los redis solo si los parámetros correspondientes son verdaderos, lo cual es necesario solo para las pruebas. En producción, crea el esquema una vez (ignorando las migraciones de esquema).

Usando MariaDB

MariaDB y SQLite son un poco diferentes en lo que respecta a DDL. Las diferencias son pequeñas, pero importantes. Go no tiene un conjunto de herramientas maduro de base de datos cruzada como el fantástico SQLAlchemy de Python, por lo que debes administrarlo tú mismo (no, Gorm no cuenta). Las principales diferencias son:

  • El controlador SQL es "github.com/go-sql-driver/mysql".
  • La base de datos no vive en la memoria, por lo que se vuelve a crear cada vez (soltar y crear).
  • El esquema debe ser una porción de declaraciones DDL independientes en lugar de una cadena de todas las declaraciones.
  • Las claves primarias de incremento automático están marcadas con AUTO_INCREMENT.
  • VARCHAR en lugar de TEXT.

Aquí está el código:

Usando Redis

Redis es muy fácil de usar desde Go. La biblioteca cliente "github.com/go-redis/redis" es muy intuitiva y sigue fielmente los comandos de Redis. Por ejemplo, para probar si existe una clave, simplemente usa el método Exits() del cliente de redis, que acepta una o más claves y devuelve cuántas de ellas existen.

En este caso, verifico solo una clave:

Prueba de acceso a múltiples almacenes de datos

Las pruebas son en realidad idénticas. La interfaz no cambió y el comportamiento no cambió. El único cambio es que la implementación ahora mantiene un caché en Redis. El método GetSongsByEmail() ahora solo llama a refreshUser_Redis().

El método refreshUser_Redis() devuelve las canciones de usuario de Redis si existen y, de lo contrario, las recupera de MariaDB.

Aquí hay un pequeño problema desde el punto de vista de la metodología de prueba. Cuando realizamos pruebas a través de la interfaz de la capa de datos abstractos, no tenemos visibilidad de la implementación de la capa de datos.

Por ejemplo, es posible que exista una gran falla en la que la capa de datos omita por completo el caché y siempre obtenga los datos de la base de datos. Las pruebas pasarán, pero no nos beneficiaremos del caché. Hablaré en la quinta parte sobre la prueba de tu caché, que es muy importante.

Conclusión

En este tutorial, cubrimos las pruebas contra una capa de datos compleja local que consta de múltiples almacenes de datos (una base de datos relacional y una caché de Redis). También utilizamos Docker para implementar fácilmente varios almacenes de datos para realizar pruebas.

En la cuarta parte, nos centraremos en las pruebas con almacenes de datos remotos, utilizando instantáneas de los datos de producción para nuestras pruebas y también generando nuestros propios datos de prueba. ¡Mantente al tanto!

Advertisement
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.