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: pruebas simuladas, pruebas de emulación y pruebas en la nube. 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 desarrolle el código localmente, pruebas de emulación para replicar mejor el comportamiento del servicio antes de la implementación y pruebas en la nube como parte de un proceso nocturno de integración y entrega continuas (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 PutObject mé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 proporcionar 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 simulado 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.
-
Es posible que las pruebas simuladas se aprueben a nivel local, pero que no funcionen en la nube porque simulan (en lugar de replicar) el comportamiento de los servicios reales, lo que hace que no se detecten los problemas específicos del entorno.
-
Los marcos simulados, como los emuladores, no pueden detectar infracciones de políticas AWS Identity and Access Management (IAM), límites de cuota de servicio o restricciones de tamaño de carga útil, ni activan servicios auxiliares como Amazon AWS CloudTrail o Amazon GuardDuty que puedan afectar al comportamiento de las aplicaciones en un entorno implementado. CloudWatch
-
Si bien los simulacros son mejores para simular lo que hará una aplicación cuando se produzca un error en la autorización o se supere una cuota, las pruebas simuladas no permiten determinar qué resultado se producirá realmente cuando el código se despliegue en el entorno de producción.
Pruebas de emulación
Las pruebas de emulación se habilitan mediante aplicaciones que se ejecutan de forma local y que se conocen como emuladores, que se asemejan a ellas. Servicios de 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 PutObject método. Cuando GetObject se 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, que se ejecuten en su máquina local para proporcionar una capacidad de prueba rápida, local y aislada.
-
No requiere ningún cambio en la infraestructura de la nube (como las cuentas en la nube de los desarrolladores), por lo que es fácil 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:
-
Suelen ser difíciles de configurar y replicar, especialmente cuando se utilizan como parte de CI/CD procesos. 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 soporte.
-
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 Servicios de AWS 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.
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:
-
Puedes realizar pruebas en la nube comparándolas con las funciones APIs y servicios más recientes, para asegurarte de que las pruebas reflejen los valores de retorno y los comportamientos más recientes a medida que AWS se lanzan nuevos servicios y capacidades.
-
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 podrían ser menos factibles si no tienes acceso a Internet de alta velocidad.
-
En los sectores regulados, las políticas de seguridad empresarial pueden restringir el acceso de los desarrolladores a los entornos de nube, lo que dificulta o imposibilita la ejecución de pruebas en la nube como parte de un flujo de trabajo de desarrollo local.
-
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 trabajan en una empresa que tiene controles estrictos en materia de cuentas e infraestructura.
