Prueba de funciones de AWS Lambda en C#

nota

Consulte el capítulo Prueba de funciones para obtener una introducción completa a las técnicas y prácticas recomendadas para probar soluciones sin servidor.

Para probar las funciones sin servidor, se utilizan tipos y técnicas de prueba tradicionales, pero también se debe considerar la posibilidad de probar las aplicaciones sin servidor en conjunto. Las pruebas basadas en la nube proporcionan la medida más precisa de la calidad tanto de las funciones como de las aplicaciones sin servidor.

Una arquitectura de aplicaciones sin servidor incluye servicios administrados que proporcionan las funcionalidades críticas de las aplicaciones mediante llamadas a la API. Por este motivo, el ciclo de desarrollo debe incluir pruebas automatizadas que verifiquen las funcionalidades cuando la función y los servicios interactúen.

Si no crea pruebas basadas en la nube, pueden surgir problemas debido a las diferencias entre su entorno local y el entorno implementado. El proceso de integración continua debe ejecutar pruebas con un conjunto de recursos aprovisionados en la nube antes de promover el código al siguiente entorno de implementación, como el control de calidad, el ensayo o la producción.

Siga leyendo esta breve guía para obtener información sobre las estrategias de prueba para aplicaciones sin servidor, o visite el repositorio de ejemplos de pruebas sin servidor a fin de profundizar en ejemplos prácticos y específicos para el lenguaje y el tiempo de ejecución de su elección.

Para las pruebas sin servidor, seguirá escribiendo unidades, integraciones y end-to-endpruebas.

• Pruebas unitarias: pruebas que se ejecutan en un bloque de código aislado. Por ejemplo, verificar la lógica empresarial para calcular los gastos de envío en función de un elemento y un destino determinados.

• Pruebas de integración: pruebas en las que participan dos o más componentes o servicios que interactúan, normalmente en un entorno de nube. Por ejemplo, verificar si una función procesa los eventos de una cola.

• nd-to-end Pruebas electrónicas: pruebas que verifican el comportamiento en toda la aplicación. Por ejemplo, garantizar que la infraestructura esté configurada correctamente y que los eventos fluyan entre los servicios tal como se espera para registrar el pedido de un cliente.

Pruebas de aplicaciones sin servidor

Por lo general, utilizará una combinación de métodos para probar el código de sus aplicaciones sin servidor, como las pruebas en la nube, las pruebas con simulaciones y, en ocasiones, las pruebas con emuladores.

Pruebas en la nube

Las pruebas en la nube son valiosas para todas las fases de las pruebas, incluidas las pruebas unitarias, las pruebas de integración y end-to-end las pruebas. Las pruebas se ejecutan con el código implementado en la nube y se interactúa con los servicios basados en la nube. Este enfoque proporciona la medida más precisa de la calidad del código.

Una forma práctica de depurar la función de Lambda en la nube es a través de la consola con un evento de prueba. Un evento de prueba es una entrada JSON a su función. Si la función no requiere una entrada, el evento puede ser un documento JSON vacío ({}). La consola proporciona ejemplos de eventos para una variedad de integraciones de servicios. Tras crear un evento en la consola, puede compartirlo con su equipo para que las pruebas sean más sencillas y coherentes.

nota

Probar una función en la consola es una forma rápida de empezar, pero la automatización de los ciclos de prueba garantiza la calidad de la aplicación y la velocidad de desarrollo.

Herramientas para pruebas

Para acelerar su ciclo de desarrollo, hay una serie de herramientas y técnicas que puede utilizar al probar sus funciones. Por ejemplo, tanto Accelerate AWS SAM como el modo de vigilancia de AWS CDK reducen el tiempo necesario para actualizar los entornos de nube.

La forma en que se define el código de la función de Lambda facilita la adición de pruebas unitarias. Lambda requiere un constructor público sin parámetros para inicializar la clase. La introducción de un segundo constructor interno le permite controlar las dependencias que utiliza su aplicación.

[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]

namespace GetProductHandler;

public class Function
{
    private readonly IDatabaseRepository _repo;
    
    public Function(): this(null)
    {
    }
    
    internal Function(IDatabaseRepository repo)
    {
        this._repo = repo ?? new DatabaseRepository();
    }
    
    public async Task<APIGatewayProxyResponse> FunctionHandler(APIGatewayProxyRequest request)
    {
        var id = request.PathParameters["id"];
        
        var databaseRecord = await this._repo.GetById(id);
        
        return new APIGatewayProxyResponse 
        {
            StatusCode = (int)HttpStatusCode.OK,
            Body = JsonSerializer.Serialize(databaseRecord)
        };
    }
}

Para escribir una prueba para esta función, puede inicializar una nueva instancia de su clase Function y pasar una implementación simulada de IDatabaseRepository. Los siguientes ejemplos utilizan XUnit, Moq y FluentAssertions para escribir una prueba sencilla que garantice que FunctionHandler devuelve un código de estado 200.

using Xunit;
using Moq;
using FluentAssertions;

public class FunctionTests
{
    [Fact]
    public async Task TestLambdaHandler_WhenInputIsValid_ShouldReturn200StatusCode()
    {
        // Arrange
        var mockDatabaseRepository = new Mock<IDatabaseRepository>();
        
        var functionUnderTest = new Function(mockDatabaseRepository.Object);
        
        // Act
        var response = await functionUnderTest.FunctionHandler(new APIGatewayProxyRequest());
        
        // Assert
        response.StatusCode.Should().Be(200);
    }
}

Para ver ejemplos más detallados, incluidos ejemplos de pruebas asíncronas, consulte el repositorio de ejemplos de pruebas de.NET en. GitHub