Técnicas de prueba para aplicaciones sin servidor - AWS Guía prescriptiva

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Técnicas de prueba para aplicaciones sin servidor

Existen tres enfoques principales para ejecutar pruebas con código de aplicaciones sin servidor: las pruebas simuladas, las pruebas en la nube y las pruebas de emulación. Por lo general, puede encontrar una combinación de estos enfoques en uso en el ámbito de un único proyecto. Por ejemplo, puede utilizar pruebas simuladas cuando desarrolla el código de forma local, pero es posible que pruebe el código en la nube como parte de un proceso nocturno de integración continua y entrega continua (CI/CD).

Pruebas simuladas

Las pruebas simuladas son una técnica en la que se crean objetos de reemplazo en el código para simular el comportamiento de un servicio en la nube. Por ejemplo, puede escribir una prueba que utilice una simulación del servicio Amazon S3 y puede configurar esa simulación para que devuelva un objeto de respuesta específico cada vez que se llame al CreateObjectmétodo. Cuando se ejecuta una prueba, la simulación devuelve la respuesta programada sin llamar a Amazon S3 ni a ningún otro punto de conexión de servicio.

Estos objetos de reemplazo a menudo se generan mediante un marco simulado para reducir la cantidad de implementación necesaria para una prueba determinada. Algunos marcos simulados son genéricos y otros están diseñados específicamente para ellos AWS SDKs.

Los simulaciones, junto con los talones, entran en la categoría más amplia de imitaciones. Los simulacros se diferencian de los emuladores (explicados más adelante en esta sección) en que los simulacros suelen ser creados o configurados por un desarrollador como parte del código de prueba, mientras que los emuladores son aplicaciones independientes que exponen APIs (como REST APIs) de la misma manera que los sistemas que emulan.

Entre las ventajas de utilizar simulaciones se incluyen las siguientes:

  • Los simuladores pueden simular servicios de terceros que están fuera del control de su aplicación, como APIs los proveedores de software como servicio (SaaS), sin necesidad de acceso directo a esos servicios.

  • Las simulaciones son útiles para probar las condiciones de error, en especial cuando esas condiciones (como las interrupciones de servicios) son difíciles de simular.

  • Al igual que los emuladores, los marcos simulados pueden brindar un desarrollo local rápido una vez configurados.

  • Las simulaciones pueden proporcionar un comportamiento sustituto para prácticamente cualquier tipo de objeto, por lo que las estrategias de simulación pueden ofrecer cobertura a una variedad de servicios más amplia que los emuladores.

  • Cuando aparecen nuevas funciones o comportamientos, las pruebas simuladas pueden reaccionar más rápidamente utilizando (o recurriendo a) un marco de simulación genérico, que puede simular las nuevas funciones en cuanto esté disponible el AWS SDK actualizado.

Las pruebas simuladas tienen las siguientes desventajas:

  • Por lo general, las simulaciones requieren un esfuerzo no trivial de preparación y configuración, especialmente cuando se trata de determinar los valores devueltos de diferentes servicios para simular correctamente las respuestas.

  • Dado que las simulaciones las escriben o configuran los desarrolladores que escriben las pruebas, esto supone una responsabilidad adicional para los desarrolladores.

  • Es posible que necesite tener acceso a la nube para comprender los valores de retorno de los servicios APIs y comprenderlos.

  • Las simulaciones también pueden ser difíciles de mantener, ya que requieren actualizaciones siempre que las firmas de las API simuladas en la nube cambien, los esquemas de valores devueltos cambien o la lógica de la aplicación probada se amplíe para hacer llamadas a nuevas aplicaciones. APIs Estos cambios crean una carga de trabajo de desarrollo de pruebas adicional para los desarrolladores.

  • Las pruebas simuladas pueden funcionar en entornos de escritorio, pero tener errores en la nube.

  • Los marcos simulados, como los emuladores, están limitados a la hora de probar o detectar las limitaciones de cuotas o AWS Identity and Access Management políticas (IAM).

  • Si bien las simulaciones son mejores para simular qué hará una aplicación cuando se produzca un error en la autorización o se supere una cuota, las pruebas simuladas no pueden determinar qué resultado se producirá realmente cuando se implemente el código en un entorno de producción.

Pruebas en la nube

Las pruebas en la nube son el proceso de ejecutar pruebas con código que se implementa en un entorno de nube en lugar de un entorno de escritorio. El valor de las pruebas en la nube aumenta con el desarrollo de aplicaciones nativas en la nube. Por ejemplo:

  • Puede realizar pruebas en la nube con los valores más recientes APIs y los valores devueltos.

  • Las pruebas pueden abarcar las políticas de IAM, las cuotas de servicio, las configuraciones y todos los servicios.

  • Su entorno de prueba en la nube es el que más se parece a su entorno de tiempo de ejecución de producción, por lo que es probable que las pruebas que ejecute en la nube tengan resultados más constantes a medida que avanzan en los entornos.

Algunos inconvenientes de las pruebas en la nube incluyen los siguientes:

  • Las implementaciones en entornos de nube suelen llevar más tiempo que las implementaciones en entornos de escritorio. Herramientas como AWS Serverless Application Model (AWS SAM) Accelerate, el modo de vigilancia de AWS Cloud Development Kit (AWS CDK) y SST ayudan a reducir la latencia relacionada con las iteraciones de implementaciones en la nube.

  • Las pruebas en la nube pueden implicar costos de servicio adicionales, a diferencia de las pruebas locales, que utilizan el entorno de desarrollo local.

  • Las pruebas en la nube pueden ser menos factibles si no tiene acceso a Internet de alta velocidad.

  • Las pruebas en la nube suelen requerir entornos de nube que estén aislados unos de otros. Los límites del entorno suelen establecerse a nivel de pila en las cuentas compartidas de los entornos de desarrolladores, a veces mediante estrategias de tipo de espacios de nombres, como el uso de prefijos para identificar la propiedad. En los entornos de preproducción y producción, los límites suelen establecerse a nivel de cuenta para aislar las cargas de trabajo de los problemas de vecinos ruidosos y respaldar controles de seguridad con privilegios mínimos a fin de proteger los datos confidenciales. El requisito de crear entornos aislados puede suponer una carga adicional para DevOps los equipos, especialmente si están en una empresa que tiene controles estrictos en materia de cuentas e infraestructura.

Pruebas de emulación

Las pruebas de emulación se realizan mediante aplicaciones que se ejecutan localmente y que se conocen como emuladores y que se asemejan a los servicios. AWS Los emuladores son similares a sus homólogos de la nube y proporcionan valores de retorno similares. APIs También pueden simular los cambios de estado que se inician mediante llamadas a la API. Por ejemplo, un emulador de Amazon S3 puede almacenar un objeto en el disco local cuando se llama al PutObjectmétodo. Cuando GetObjectse llama con la misma clave, el emulador lee el mismo objeto del disco y lo devuelve.

Algunas ventajas de realizar pruebas de emulación incluyen las siguientes:

  • Los emuladores brindan un entorno conocido para los desarrolladores acostumbrados a desarrollar código exclusivamente en un entorno local. Por ejemplo, si está familiarizado con el desarrollo de una aplicación de n niveles, es posible que tenga un motor de base de datos y un servidor web, similares a los que se ejecutan en producción, en su equipo local para proporcionar una capacidad de prueba rápida, local y aislada.

  • Los emuladores no requieren ningún cambio en la infraestructura de la nube (como las cuentas en la nube de los desarrolladores), por lo que son fáciles de implementar con los patrones de prueba existentes. Las pruebas de emulación ofrecen los beneficios de las iteraciones rápidas de desarrollo local.

Sin embargo, los emuladores tienen varios inconvenientes:

  • A menudo son difíciles de configurar y replicar, en especial cuando se utilizan como parte de las canalizaciones de CI/CD. Esto podría aumentar la carga de trabajo y el mantenimiento del personal de TI o de los desarrolladores que administran sus propias instalaciones de software.

  • Las funciones emuladas APIs suelen ir a la zaga de los cambios en los servicios y pueden dificultar la adopción de nuevas funciones hasta que se añada la compatibilidad.

  • Es posible que los emuladores necesiten asistencia, actualizaciones, correcciones de errores o mejoras en la paridad de características, lo cual es responsabilidad del autor del emulador (que suele ser una empresa externa).

  • Las pruebas que se basan en emuladores pueden ofrecer resultados satisfactorios a nivel local, pero pueden fallar en la nube debido a la interacción con otros aspectos, AWS como las políticas y las cuotas de IAM, que por lo general no se emulan.

  • Algunos AWS servicios no tienen emuladores disponibles, por lo que si solo confías en la emulación, es posible que no tengas una opción de prueba satisfactoria para algunas partes de la aplicación.