Advertisement
  1. Code
  2. Go

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

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 3
Testing Data-Intensive Code With Go, Part 5

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

Visión general

Esta es la cuarta parte de cinco de una serie de tutoriales sobre cómo probar código con uso intensivo de datos con Go. En la tercera parte, cubrí las pruebas contra una capa de datos compleja local que incluye una base de datos relacional y una caché de Redis.

En este tutorial, repasaré las pruebas con almacenes de datos remotos usando bases de datos de prueba compartidas, usando instantáneas de datos de producción y generando tus propios datos de prueba.

Prueba contra almacenes de datos remotos

Hasta ahora, todas nuestras pruebas se realizaron localmente. A veces, eso no es suficiente. Es posible que debas realizar pruebas con datos que sean difíciles de generar u obtener localmente. Los datos de prueba pueden ser muy grandes o cambiar con frecuencia (por ejemplo, instantánea de datos de producción).

En estos casos, puede resultar demasiado lento y costoso para cada desarrollador copiar los datos de prueba más recientes en su máquina. A veces, los datos de prueba son confidenciales y, especialmente, los desarrolladores remotos no deberían tenerlos en su computadora portátil.

Aquí hay varias opciones para considerar. Puedes utilizar una o más de estas opciones en diferentes situaciones.

Base de datos de prueba compartida

Ésta es una opción muy común. Existe una base de datos de prueba compartida a la que todos los desarrolladores pueden conectarse y probar. Esta base de datos de prueba compartida se administra como un recurso compartido y, a menudo, se llena periódicamente con algunos datos de referencia, y luego los desarrolladores pueden ejecutar pruebas en ella que consultan los datos existentes. También pueden crear, actualizar y eliminar sus propios datos de prueba.

En este caso, necesitas mucha disciplina y un buen proceso en marcha. Si dos desarrolladores ejecutan la misma prueba al mismo tiempo que crean y eliminan los mismos objetos, ambas pruebas fallarán. Ten en cuenta que incluso si eres el único desarrollador y una de tus pruebas no se limpia después de sí misma correctamente, tu próxima prueba puede fallar porque la base de datos ahora tiene algunos datos adicionales de la prueba anterior que pueden romper tu prueba actual.

Ejecución de las pruebas de forma remota

Así es como funcionan las canalizaciones de CI/CD o incluso los sistemas de compilación automatizados. Un desarrollador confirma un cambio y comienza a ejecutarse una compilación y una prueba automatizadas. Pero también puedes simplemente conectarte a una máquina remota que tenga tu código y ejecutar tus pruebas allí.

El beneficio es que puedes replicar la configuración local exacta, pero tienes acceso a los datos que ya están disponibles en el entorno remoto. La desventaja es que no puedes usar tus herramientas favoritas para depurar.

Instancia de prueba remota ad-hoc

El lanzamiento de una instancia de prueba ad-hoc remota garantiza que aún estés aislado de otros desarrolladores. Es bastante similar conceptualmente a ejecutar una instancia local. Aún necesitas iniciar tu almacén de datos (o almacenes). Aún debes completarlos (de forma remota). Sin embargo, tu código de prueba se ejecuta localmente y puedes depurar y solucionar problemas con tu IDE favorito (Gogland en mi caso). Puede ser difícil de administrar operativamente si los desarrolladores mantienen en ejecución las instancias de prueba después de que se realizan las pruebas.

Uso de instantáneas de datos de producción

Cuando se utiliza un almacén de datos de prueba compartido, a menudo se completa con instantáneas de datos de producción. Dependiendo de cuán sensibles y críticos sean los datos, algunos de los siguientes pros y contras pueden ser relevantes.

Ventajas y desventajas de utilizar datos de producción para realizar pruebas

Pros:

  • Prueba con datos reales. Si funciona, estás bien.
  • Puedes cargar y realizar pruebas de rendimiento que representen una carga real.
  • No es necesario escribir generadores de datos que intenten simular datos de producción reales.

Contras:

  • Puede que no sea fácil probar las condiciones de error.
  • Los datos de producción pueden ser confidenciales y requerir un tratamiento especial.
  • Necesitas escribir algún código o sincronizar manualmente tu instantánea periódicamente.
  • Tienes que lidiar con cambios de formato o esquema.
  • Puede ser difícil aislar los problemas que aparecen con datos de producción desordenados.

Anonimizar datos de producción

Bien. Has dado el salto y has decidido utilizar una instantánea de datos de producción. Si tus datos involucran a personas en cualquier forma o figura, es posible que debas anonimizar los datos. Esto es sorprendentemente difícil.

No puedes simplemente reemplazar todos los nombres y terminar con eso. Hay muchas formas de recuperar PII (información de identificación personal) y PHI (información de salud protegida) a partir de instantáneas de datos mal anonimizadas. Consulta Wikipedia como punto de partida si tienes curiosidad.

Trabajo para Helix, donde desarrollamos una plataforma de genómica personal que se ocupa de los datos más privados: el ADN secuenciado de las personas. Tenemos algunas salvaguardas serias contra violaciones de datos accidentales (y maliciosas).

Actualización de pruebas e instantáneas de datos

Cuando utilices instantáneas de datos de producción, deberás actualizar periódicamente tus instantáneas y, en consecuencia, tus pruebas. El tiempo depende de ti, pero definitivamente hazlo siempre que haya un cambio de esquema o formato.

Idealmente, tus pruebas no deberían probar las propiedades de una instantánea en particular. Por ejemplo, si actualizas tus instantáneas diariamente y tienes una prueba que verifica la cantidad de registros en la instantánea, tendrás que actualizar esta prueba todos los días. Es mucho mejor escribir tus pruebas de una manera más genérica, por lo que debes actualizarlas solo cuando cambies el código bajo prueba.

Generando datos de prueba

Otro enfoque es generar tus propios datos de prueba. Los pros y los contras son exactamente los opuestos del uso de instantáneas de datos de producción. Ten en cuenta que también puedes combinar los dos enfoques y ejecutar algunas pruebas en instantáneas de datos de producción y otras pruebas utilizando datos generados.

Generación aleatoria de datos de prueba

¿Cómo harías para generar tus datos de prueba? Puedes volverte loco y usar datos totalmente aleatorios. Por ejemplo, para Songify podemos generar cadenas totalmente aleatorias para el correo electrónico del usuario, la URL, la descripción y las etiquetas. El resultado será caótico, pero datos válidos ya que Songify no realiza ninguna validación de datos.

Aquí hay una función simple para generar cadenas aleatorias:

Escribamos una función que agregue cinco usuarios aleatorios y luego agregue 100 canciones aleatorias distribuidas al azar entre los cinco usuarios. Debemos generar usuarios porque las canciones no viven en el vacío. Cada canción siempre está asociada con al menos un usuario.

Ahora, podemos escribir algunas pruebas que operen con una gran cantidad de datos. Por ejemplo, aquí hay una prueba que verifica que podemos obtener las 100 canciones en una llamada. Ten en cuenta que la prueba llama a PopulateWithRandomData() antes de realizar la llamada.

Generación de datos de prueba basada en reglas

Por lo general, los datos completamente aleatorios no son aceptables. Cada almacén de datos tiene restricciones que debes respetar y relaciones complejas que deben seguirse para crear datos válidos con los que el sistema pueda operar. Es posible que también desees generar algunos datos no válidos para probar cómo lo maneja el sistema, pero esos serán errores específicos que inyectarás.

El enfoque será similar a la generación de datos aleatorios, excepto que tendrás más lógica para hacer cumplir las reglas.

Por ejemplo, digamos que queremos hacer cumplir la regla de que un usuario puede tener como máximo 30 canciones. En lugar de crear 100 canciones al azar y asignarlas a los usuarios, podemos decidir que cada usuario tendrá exactamente 20 canciones, o tal vez crear un usuario sin canciones y otros cuatro usuarios con 25 canciones cada uno.

Generación de datos de prueba basada en narrativas

En algunos casos, generar datos de prueba es muy complicado. Recientemente trabajé en un proyecto que tenía que inyectar datos de prueba a cuatro microservicios diferentes, cada uno administrando su propia base de datos con los datos en cada base de datos relacionados con los datos en otras bases de datos. Fue bastante desafiante y laborioso mantener todo sincronizado.

Por lo general, en tales situaciones es más fácil utilizar las API del sistema y las herramientas existentes que crean datos en lugar de ir directamente a múltiples almacenes de datos y rezar para que no rompa la estructura del universo. No pudimos adoptar este enfoque porque en realidad necesitábamos crear algunos datos no válidos intencionalmente para probar varias condiciones de error y omitir algunos efectos secundarios relacionados con los sistemas externos que ocurren durante el flujo de trabajo normal.

Conclusión

En este tutorial, cubrimos las pruebas con almacenes de datos remotos, el uso de bases de datos de prueba compartidas, el uso de instantáneas de datos de producción y la generación de tus propios datos de prueba.

En la quinta parte, nos centraremos en las pruebas de fuzz, probar tu caché, probar la integridad de los datos, probar la idempotencia y los datos faltantes. 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.