Conceptos básicos de las pruebas

En este documento, se ofrece una descripción general de los conceptos básicos de las pruebas, lo que incluye lo siguiente:

Tipos de pruebas

En esta guía, se tratan tres tipos comunes de pruebas que puedes usar para asegurarte de que tu código funcione correctamente:

  • Pruebas de unidades
  • Pruebas de integración
  • Pruebas del sistema

En general, las pruebas más rigurosas tardan más tiempo en completarse. En este documento, se analizan estos tipos de pruebas en detalle y se ofrecen algunas sugerencias para lograr un equilibrio entre rapidez y rigurosidad.

Pruebas de unidades

Las pruebas de unidades son pruebas de poco alcance para partes pequeñas y específicas de tu código. Estas pruebas pueden verificar rápidamente las suposiciones hechas durante el proceso de desarrollo, como el manejo de casos extremos y la validación de entradas.

Por su diseño, las pruebas de unidades no comprueban la integración con dependencias externas, como Cloud Functions o algunos otros componentes de Google Cloud. Puedes usar tu marco de trabajo de simulación para crear versiones simuladas de dependencias externas.

Para las funciones de HTTP, las pruebas deben simular la unión de marcos de trabajo de HTTP. Confirma el comportamiento de la función mediante la combinación de marcos de trabajo de prueba y de simulación, y compara los resultados de tu función con los valores esperados.

Pruebas de integración

Las pruebas de integración validan la interacción entre partes de tu código y, por lo general, tardan un tiempo prudencial en completarse. Por ejemplo, en Cloud Functions, las pruebas de integración pueden usarse para probar el uso de otros servicios de Google Cloud de una función, como Datastore o Cloud Vision.

La diferencia principal entre las pruebas de unidades y las de integración en relación con Cloud Functions es que las últimas implican menos simulación que las primeras. Las pruebas de integración deben activar los eventos de nube reales y responder a ellos, como las solicitudes HTTP, los mensajes de Pub/Sub o los cambios de objeto de Storage.

Puedes ejecutar estas pruebas de manera local mediante un corrector de compatibilidad.

Algunas operaciones asíncronas pueden requerir sondeo periódico. Recomendamos usar la estrategia de sondeo de retirada exponencial truncada, ya que minimiza eficazmente tanto la latencia de la operación subyacente como la frecuencia de sondeo requerida. La retirada exponencial truncada es una estrategia estándar de manejo de errores para aplicaciones de red en la que un cliente vuelve a intentar realizar una solicitud con errores de forma periódica, cada vez con más demoras entre las solicitudes.

Pruebas de sistema

Las pruebas del sistema son más complejas, ya que validan el comportamiento de Cloud Functions a través de varios componentes de Google Cloud en un entorno de pruebas aislado.

Implementa tu función de Cloud Functions en un entorno de pruebas y evalúa su funcionalidad mediante la activación de eventos apropiados. Para validar tu función, lee los registros o revisa el comportamiento deseado.

Prácticas recomendadas para entornos de prueba

Primero, asegúrate de aislar tus entornos de desarrollo, prueba y producción. Para garantizar compilaciones herméticas, recomendamos aprovisionar de manera programática recursos de prueba con sus proyectos únicos de GCP o nombres de recursos.

En segundo lugar, recomendamos asignar recursos usados por los nombres únicos a nivel global de las pruebas de sistema para evitar que las pruebas simultáneas interfieran entre sí. Puedes hacerlo mediante la creación y eliminación programática de los recursos requeridos antes y después de cada ejecución de la prueba.

Por último, recomendamos mantener los valores de configuración separados de tu base de código. Los valores no secretos se pueden almacenar como variables de entorno, mientras que los valores secretos (como las contraseñas de base de datos y las claves de API) se deben almacenar con Secret Manager.