Conceptos básicos de las pruebas

En este documento, se ofrece una descripción general de los conceptos básicos de las pruebas, 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 prueban la integración con dependencias externas, como Cloud Functions o algunos otros componentes de Google Cloud Platform. 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 que hace una función de los servicios de GCP, como Cloud 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 requieren 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 Cloud Pub/Sub o los cambios de objeto de Storage.

Puedes ejecutar estas pruebas de manera local con 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 del sistema

Las pruebas del sistema son más complejas, ya que validan el comportamiento de tu función de Cloud Functions a través de varios componentes de GCP 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 relevantes. Para validar tu función, lee los registros o revisa el comportamiento deseado.

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

Aprovisiona un entorno de prueba

También debes asignar nombres únicos a nivel global a los recursos de prueba de sistema para evitar que 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.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Cloud Functions