DEV Community: Henk Sandoval

Cómo hacer Integration Tests con WebApplicationFactory y TDD con .NET

Henk Sandoval — Mon, 22 Jan 2024 14:00:13 +0000

Bienvenidos al primer artículo de una serie dedicada a explorar las pruebas de integración en .NET utilizando WebApplicationFactory y TDD. Sumérgete en este viaje y vamos a desentrañar las mejores prácticas y herramientas para mantener la calidad del software en un mundo que no cesa de cambiar.

Introducción: La evolución segura en el mundo del software

Las empresas son entidades que viven en constante cambio, buscando adaptarse y mejorar para mantener su competitividad en un mercado siempre en evolución. En la vanguardia de esta transformación se encuentra el software, que como herramienta vital de la modernidad, debe evolucionar de la misma manera: de forma segura y confiable. Fallas en el software pueden desencadenar consecuencias graves, desde una imagen deteriorada hasta la pérdida significativa de clientes.

En este entorno de cambio continuo, las metodologías de pruebas de software adquieren un rol protagónico. Entre ellas, las pruebas de integración se destacan por validar la cohesión entre los distintos componentes de nuestros sistemas. Sin embargo, su ejecución puede ser un reto, requiriendo tiempo y recursos significativos, además de la complejidad inherente a su diseño y ejecución.

Imagina un cambio de código menor que se despliega a producción sin una segunda revisión. Todo parece estar bien hasta que las llamadas de los clientes comienzan: "¡El sistema está caído!" Este escenario, aunque dramático, ilustra la necesidad crítica de pruebas de integración eficientes. WebApplicationFactory en .NET proporciona una poderosa herramienta para evitar tales catástrofes, permitiendo que los desarrolladores testeen sus aplicaciones en un entorno que simula el servidor real.

WebApplicationFactory: Un puente hacia la confianza en el código

Para abordar estos desafíos, .NET presenta WebApplicationFactory, una herramienta clave del paquete Microsoft.AspNetCore.Mvc.Testing. Esta clase ingeniosa permite la ejecución de un cliente de pruebas que se comunica con una instancia en memoria de un entorno de servidor real de nuestra aplicación .NET. Esto nos facilita realizar solicitudes HTTP y recibir respuestas sin la necesidad de un despliegue completo, permitiendo pruebas de integración más rápidas y menos costosas.

Beneficios de WebApplicationFactory

Entorno de prueba realista: WebApplicationFactory configura un entorno de servidor real que se ejecuta en memoria. Esto significa que las pruebas pueden interactuar con la aplicación de una manera que es muy cercana a cómo lo haría un cliente real, como un navegador web o un cliente HTTP.
Configuración de pruebas simplificada: Automatiza la configuración del host y el servidor web basándose en la configuración de producción, pero con la flexibilidad de sobrescribir dicha configuración para las pruebas.
Aislamiento: Permite configurar de manera independiente cada instancia de WebApplicationFactory, asegurando un aislamiento efectivo entre pruebas.
Inyección de dependencias: Permite la inyección de dependencias de prueba dentro de la aplicación, lo que facilita el reemplazo de servicios reales por versiones simuladas (mocks) o falsas (fakes) brindando un control preciso del entorno de pruebas.
Pruebas de sub-sistemas: Habilita la prueba de componentes individuales como bases de datos, sistemas de archivos, APIs de terceros, etc., en un entorno que simula cómo interactuarían con la aplicación completa.
Soporte para cookies y autenticación: Permite probar flujos de trabajo que involucran autenticación y manejo de sesiones, ya que el servidor de prueba maneja cookies y cabeceras HTTP de forma similar a como lo haría en producción.
Facilidad para realizar solicitudes HTTP: Al proporcionar un cliente HTTP preconfigurado, facilita la realización de solicitudes HTTP a la aplicación sin necesidad de configurar manualmente cabeceras, tokens de autenticación, etc.

Con WebApplicationFactory, el equipo de .NET nos ofrece una solución robusta para abordar las complejidades de las pruebas de integración, permitiéndonos centrarnos más en la calidad del código y la entrega de valor a nuestros usuarios.

Ejemplo Práctico: Implementación de WebApplicationFactory

Agregar WebApplicationFactory en nuestra solución.

Agregar una referencia al paquete Microsoft.AspNetCore.Mvc.Testing.

Puedes hacerlo de varias maneras:

Utiliza el administrador de paquetes NuGet de tu IDE favorito.
A través de la interfaz de línea de comandos de .NET, ejecuta el siguiente comando: dotnet add package Microsoft.AspNetCore.Mvc.Testing --version 8.0.1
Modifica directamente el archivo de proyecto (.csproj) de tu aplicación para incluir la referencia: <PackageReference Include="Microsoft.AspNetCore.Mvc.Testing" Version="8.0.1" />

Habilitar el acceso a la clase Program.

Para que WebApplicationFactory pueda funcionar correctamente, necesita acceder a la clase Program de tu aplicación:

Concede acceso a los tipos internal de tu aplicación al proyecto de pruebas agregando lo siguiente a tu archivo .csproj:

    <ItemGroup>
        <InternalsVisibleTo Include="NombreProyectoDePruebas" />
    </ItemGroup>

O bien, haciendo que la clase Program sea pública con una declaración parcial en el archivo de inicio de tu aplicación:

    public partial class Program { }

Configurando WebApplicationFactory en nuestra API

Para ilustrar cómo se usa WebApplicationFactory, consideremos un controlador de ejemplo con una Minimal API. Este controlador gestiona dos llamadas una GET y otra POST.

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

var toDoItems = new List<ToDoItem>
{
    new() { Id = 1, Title = "Do laundry", Completed = false },
    new() { Id = 2, Title = "Take out trash", Completed = false }
};

app.MapGet("/api/todo", () => toDoItems)
    .WithName("GetAll")
    .Produces(StatusCodes.Status200OK);

app.MapPost("/api/todo", (ToDoItem toDoItem, HttpContext http) =>
    {
        toDoItem.Id = toDoItems?.Max(item => item.Id) + 1 ?? 1;
        toDoItems?.Add(toDoItem);

        var location = $"{http.Request.Path}/{toDoItem.Id}";
        return Results.Created(location, toDoItem);
    })
    .WithName("CreateToDoItem")
    .Produces<ToDoItem>(StatusCodes.Status201Created);

app.Run();

public class ToDoItem
{
    public int Id { get; set; }
    public string Title { get; set; }
    public bool Completed { get; set; }
}

public abstract partial class Program { }

Ahora, veamos cómo podríamos probar este controlador utilizando WebApplicationFactory. Para ello, vamos a crear una clase de prueba que implemente la interfaz IClassFixture para inicializar mediante WebApplicationFactory nuestro entorno de pruebas.

using System.Net;
using System.Text;
using Microsoft.AspNetCore.Mvc.Testing;
using Newtonsoft.Json;

namespace TodoApi.Integration.Tests;

public class ToDoControllerTests(WebApplicationFactory<Program> factory) : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly HttpClient client = factory.CreateClient();

    [Fact]
    public async Task GetAll_ReturnsToDoItems()
    {
        // Act
        var response = await client.GetAsync("/api/todo");

        // Assert
        response.EnsureSuccessStatusCode();
        var toDoItems = JsonConvert.DeserializeObject<List<ToDoItem>>(await response.Content.ReadAsStringAsync());
        Assert.NotNull(toDoItems);
        Assert.True(toDoItems.Count > 0);
    }

    [Fact]
    public async Task Create_AddsToDoItem()
    {
        // Arrange
        var newItem = new ToDoItem { Title = "Test task", Completed = false };
        var httpContent = new StringContent(JsonConvert.SerializeObject(newItem), Encoding.UTF8, "application/json");

        // Act
        var response = await client.PostAsync("/api/todo", httpContent);

        // Assert
        Assert.Equal(HttpStatusCode.Created, response.StatusCode);
        var createdItem = JsonConvert.DeserializeObject<ToDoItem>(await response.Content.ReadAsStringAsync());
        Assert.NotNull(createdItem);
        Assert.Equal("Test task", createdItem.Title);
        Assert.False(createdItem.Completed);
        Assert.True(createdItem.Id > 0);
    }
}

En este ejemplo de prueba:

Utilizamos IClassFixture<WebApplicationFactory<Program>> para indicar que nuestra clase de pruebas usará una instancia de WebApplicationFactory con la configuración definida en la clase Program de nuestra API.
Creamos un cliente HTTP con CreateClient(), que no requiere que el servidor Kestrel esté escuchando en un puerto TCP real.
Realizamos peticiones HTTP asincrónicas al EndPoint de nuestra API y verificamos que la respuesta sea exitosa y que el contenido sea del tipo esperado.
Deserializamos el contenido de la respuesta y validamos que contenga los datos esperados.

Si deseas ver el código en un sistema, te invito a visitarlo en mi repositorio de GitHub. Repositorio de GitHub

Conclusión y próximos pasos

WebApplicationFactory es más que una herramienta; es un aliado en el desafío de mantener la calidad y la confianza en el software que evoluciona rápidamente.

Te animo a poner en práctica estos conocimientos con WebApplicationFactory en tu entorno de desarrollo. Y mientras avanzas, recuerda que este es solo el comienzo. En artículos futuros, exploraremos más a fondo las pruebas de integración y cómo las prácticas de Desarrollo Guiado por Pruebas (TDD por sus siglas en inglés, Test Driven Development) pueden transformar tu proceso de desarrollo en .NET.

Tus preguntas, comentarios y experiencias son bienvenidos y serán el combustible para futuras discusiones y mejoras. Tu participación es crucial: comparte tus preguntas y experiencias, y únete a la conversación para elevar nuestras prácticas de desarrollo.

Recuerda, cada prueba que escribimos no sólo verifica una funcionalidad, sino que también refleja nuestro compromiso con la excelencia en el código que entregamos. ¡Adelante, y hagamos que cada línea de código cuente!

Fuentes

Integration tests in ASP.NET Core learn.microsoft.com/.

Clean Code: Escribir Código Mantenible

Henk Sandoval — Sun, 07 Jan 2024 00:07:32 +0000

Desarrollar aplicaciones por primera vez no es una tarea sencilla. Es un desafío, y a veces, agotador. Sin embargo, mantener y actualizar aplicaciones existentes puede ser aún más complicado por varias razones:

Falta de conocimientos adecuados.
Estilos de codificación avanzados y personales de otros desarrolladores.
Escasez o ausencia de documentación, lo cual puede ser frustrante, especialmente si no se alinea con el código.

La comodidad de conformarse con código que "simplemente funciona" a menudo prevalece, ignorando su sostenibilidad o legibilidad a largo plazo. ¿Cuántas veces hemos enfrentado código legado que parece un jeroglífico moderno? Personalmente, más veces de las que me gustara admitir y, en ocasiones, he sido yo quien ha contribuido a ese caos.

Generar código complejo y enredado, sin pruebas unitarias, o con nombres de variables crípticos, es una garantía de pérdida de tiempo para quienes, en el futuro, intenten descifrarlo.

¿Por qué Importa el Código Limpio?

El código que escribes hoy es el legado que dejas para el futuro. No se trata solo de cumplir con una tarea; es esencial hacerlo de tal forma que sea comprensible y mantenible a largo plazo, ya sea por ti o por quien herede tu trabajo.

Imagina volver a tu código seis meses después o entregarlo a un colega. ¿Entenderán la lgica?, ¿Pueden agregar fácilmente nuevas caractersticas sin romper la funcionalidad existente? Ahí es donde el código limpio entra en juego.

Como anedocta personal, hace poco tiempo, tras cumplir apresuradamente con un requerimiento de negocio, cerré la tarea y pasé al siguiente proyecto. Dos meses después, al enfrentarme a un nuevo requerimiento en el mismo dominio, me di cuenta de que no entendía mi propio código. Era un laberinto de herencias, genéricos y funciones anidadas. Por suerte, una amplia cobertura de pruebas me permitió refactorizar sin miedo a dañar la funcionalidad existente. Para garantizar la claridad esta vez, solicité la revisión y el feedback de mis compañeros. Esa experiencia frustrante me motivó a retomar este viejo post y compartir estas reflexiones con ustedes.

En las siguientes secciones, no solo hablaré sobre Código Limpio; intentar mostrarles cmo un buen código puede mejorarse aún más con la aplicación de pequeñas mejoras.

Los Principios del Clean Code ^[1]

En su influyente obra " Clean Code", Robert C. Martin , también conocido como Uncle Bob, comparte una serie de principios fundamentales para la escritura de código de alta calidad. A continuación, detallamos algunas de estas ideas esenciales, que pueden transformar el código de aceptable a excepcional.

Nombres Significativos ^[2]

Elige nombres que comuniquen claramente la intención detrás de una variable, función o clase. Por ejemplo, diasDesdeCreacion es más descriptivo que dias. Un buen nombre es autoexplicativo y puede reducir la dependencia de comentarios adicionales.

Evitar los "Números Mágicos" ^[3]

Los "números mágicos" son valores numéricos con significados no obvios. Reemplazarlos con constantes nombradas mejora la comprensión del código. Así, const HORAS_EN_UN_DIA = 24; es más claro que usar el número 24 directamente en el código.

Las Funciones Deben Hacer Una Sola Cosa ^[4]

Cada función debe estar diseñada para realizar una sola acción bien definida. Esto facilita las pruebas, la depuracin y la lectura del código. Si una funcin est verificando el acceso del usuario y luego actualizando un registro, considera dividirla en dos funciones distintas.

Keep it simple, Stupid (KISS) ^[5]

Evita complicar el código innecesariamente. La solución más simple y directa es a menudo la mejor opción. Esto es crucial para mantener el código manejable y reducir el riesgo de errores.

Don't Repeat Yourself (DRY) ^[6]

La duplicación de código es una fuente común de errores. Utiliza abstracciones para evitar repetir la misma lógica. Sin embargo, ten cuidado de no caer en la trampa de la abstraccin excesiva en nombre de DRY, lo cual puede llevar a una complejidad innecesaria.

Escribe Pruebas Unitarias ^[7]

El desarrollo de pruebas unitarias debe ir de la mano con la escritura de código. Estas pruebas son esenciales para validar que cada componente del sistema funciona como se espera y para mitigar el miedo a los cambios que puedan introducir errores.

Refactoriza Regularmente ^[8]

La refactorización no debe verse como una tarea que se realiza una sola vez. Es un aspecto continuo del desarrollo de software. Dedica tiempo a revisar y mejorar el código, buscando oportunidades para aplicar los principios de Clean Code.

Estos principios son más que simples reglas; son la base para escribir código que no solo es funcional sino también sostenible y agradable de trabajar. En la próxima sección, analizaremos cómo aplicar estos principios de manera efectiva, asegurando que nuestro código no solo funcione, sino que también sea elegante y fácil de mantener.

Ejemplo de Refactorización .NET

Al revisar el código fuente de una aplicación, me encontré con el siguiente método que, aunque escrito con cuidado, presentaba oportunidades para alinearse más estrechamente con las prácticas recomendadas de Clean Code.

Inicialmente, el método se vea así:

using System.Linq.Expressions;
using Microsoft.EntityFrameworkCore;

namespace BlogExamples.CleanCode;

public class Repository<TEntity> where TEntity: class, IEntity
{
    private readonly DbSet<TEntity> dbSet;

    public Repository(DbContext dbContext)
    {
        dbSet = dbContext.Set<TEntity>();
    }

    public async Task<PaginatedEntityModel<TEntity>> GetAllAsync(Expression<Func<TEntity, bool>> filterExpression, Expression<Func<TEntity, string>> orderExpression, PaginationModel paginationModel)
    {
        IQueryable<TEntity> query = dbSet.Where(filterExpression);
        double iTotal = await query.CountAsync();
        int skip = paginationModel.Page - 1 * paginationModel.RecordsPerPage;

        IList<TEntity> entities = await query
            .OrderBy(orderExpression)
            .Skip(skip)
            .Take(paginationModel.RecordsPerPage)
            .ToListAsync();

        PaginatedEntityModel<TEntity> paginatedEntities = new PaginatedEntityModel<TEntity>
        {
            Entities = entities,
            TotalRecordCount = iTotal,
            CurrentPage = paginationModel.Page,
            RecordsPerPage = paginationModel.RecordsPerPage,
            TotalPages = Math.Ceiling(iTotal / paginationModel.RecordsPerPage)
        };

        return paginatedEntities;
    }
}

public class PaginatedEntityModel<TEntity> where TEntity : class, IEntity
{
    public IList<TEntity> Entities { get; set; }
    public int CurrentPage { get; set; }
    public int RecordsPerPage { get; set; }
    public double TotalRecordCount { get; set; }
    public double TotalPages { get; set; }
}

public interface IEntity {}

public record PaginationModel(int Page, int RecordsPerPage);

En principio, el código me parece bastante acertado y dira que escrito con cariño. Sin embargo, propondra algunas mejoras para ser consistentes con las mejores practicas del CleanCode.

Claridad y legibilidad : Corregir los nombres de las variables para que sean consistentes y descriptivos. Por ejemplo, cambiar iTotal por totalRecordCount, lo que es más descriptivo de lo que la variable est almacenando.
Responsabilidad única : Trasladar la lógica del cálculo de cantidad de registros a omitir y del total de páginas a mtodos propios.
Uso de comentarios con sentido : Incorporar un comentario para justificar el número mágico 1 (que con mi conocimiento es imposible explicar sin un comentario).
Evitar números mágicos : Corregir la precedencia de los operadores en el cálculo de skip para evitar malentendidos y errores.
Robustez : Agregar validaciones para paginationModel y entities para evitar la creación de instancias en un estado invlido.
Encapsulamiento y validación : Agregar un constructor a PaginatedEntityModel para asegurar que todos los valores proporcionados sean válidos, lo que refuerza la integridad del modelo de paginación.
Mantenibilidad : Trasladar la lógica para calcular el total de páginas a un método privado, facilitando el mantenimiento, mejorando la cohesin y evitando la duplicacin de cdigo.

Con las mejoras propuestas, el código refactorizado quedara de la siguiente manera, tambin puedes explorar los cambios mediante GitDiff en este enlace de mi repositorio de GitHub

using System.Linq.Expressions;
using Microsoft.EntityFrameworkCore;

namespace BlogExamples.CleanCode;

public class Repository<TEntity> where TEntity: class, IEntity
{
    private readonly DbSet<TEntity> dbSet;

    public Repository(DbContext dbContext)
    {
        dbSet = dbContext.Set<TEntity>();
    }

    public async Task<PaginatedEntityModel<TEntity>> GetAllAsync(
        Expression<Func<TEntity, bool>> filterExpression, 
        Expression<Func<TEntity, string>> orderExpression, 
        PaginationModel paginationModel)
    {
        if (paginationModel is null)
        {
            throw new ArgumentNullException(nameof(paginationModel));
        }

        IQueryable<TEntity> query = dbSet.Where(filterExpression);
        double totalRecordCount = await query.CountAsync();
        int skip = CalculateSkip(paginationModel.Page, paginationModel.RecordsPerPage);

        IList<TEntity> entities = await query
            .OrderBy(orderExpression)
            .Skip(skip)
            .Take(paginationModel.RecordsPerPage)
            .ToListAsync();

        return new PaginatedEntityModel<TEntity>(entities, totalRecordCount, paginationModel);
    }

    private static int CalculateSkip(int page, int recordsPerPage)
    {
        // Calculate the number of records to skip by converting the 1-based page number to 
        // a 0-based index and multiplying by the number of records per page. 
        // This aligns Page 1 with a skip of 0 records, ensuring the first page starts with the first record.
        return (page - 1) * recordsPerPage;
    }
}

public class PaginatedEntityModel<TEntity> where TEntity : class, IEntity
{
    public IList<TEntity> Entities { get; }
    public int CurrentPage { get; }
    public int RecordsPerPage { get; }
    public double TotalRecordCount { get; }
    public double TotalPages => CalculateTotalPages();

    public PaginatedEntityModel(IList<TEntity> entities, double totalRecordCount, PaginationModel paginationModel)
    {
        Entities = entities ?? throw new ArgumentNullException(nameof(entities));
        TotalRecordCount = totalRecordCount >= 0 ? totalRecordCount 
            : throw new ArgumentOutOfRangeException(nameof(totalRecordCount));
        CurrentPage = paginationModel.Page;
        RecordsPerPage = paginationModel.RecordsPerPage;
    }

    private double CalculateTotalPages()
    {
        return Math.Ceiling(TotalRecordCount / RecordsPerPage);
    }
}

public interface IEntity {}

public record PaginationModel(int Page, int RecordsPerPage);

Conclusión

A lo largo de esta discusión, hemos explorado el valor innegable de adherirse a los principios de código limpio y hemos iniciado el proceso de transformar un bloque de código en algo más mantenible y comprensible. Sin embargo, nuestro viaje hacia la mejora del código no termina aquí.

En nuestra próxima entrega, nos zambulliremos aún más profundamente en el arte de la refactorización. Desmenuzaremos técnicas específicas y las aplicaremos a una variedad de "olores" de código, esos indicadores sutiles pero reveladores de problemas subyacentes. Más que simples instrucciones, compartiremos las herramientas y el razonamiento para identificar cuándo y cómo actuar ante estos desafíos comunes.

Recuerda que la búsqueda del código limpio no es un ejercicio de perfeccionismo ni un riguroso cumplimiento de reglas inmutables. Más bien, es un compromiso continuo para escribir código que no solo funcione, sino que tambin sea accesible, manejable y escalable para tu equipo y para ti mismo en el futuro.

Así que mantengan su mente inquisitiva y su teclado listo; hay un mundo de código esperando ser refinado. Estén atentos para la próxima entrega y prepárense para llevar su habilidad de refactorización al siguiente nivel!

Fuentes

¹ Martin, Robert C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Pearson. Disponible en Amazon.
² Martin, Robert C. Clean Code: Fundamentals, Episode 2 - Names++. CleanCoders.com.
³ Replace Magic Number with Symbolic Constant en Refactoring Guru. Disponible en Refactoring.guru.
⁴ Martin, Robert C. (2014, May 8). The Single Responsibility Principle. Clean Coder Blog.
⁵ KISS (Keep it Simple, Stupid) - A Design Principle. Interaction Design Foundation. Disponible en Interaction-Design.org.
⁶ Hunt, Andrew; Thomas, David (1999). The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley.
⁷ Exeal (2023, October). Prctica deliberada: una forma alternativa de aprender TDD. Disponible en Exeal.com.
⁸ Exeal (2021, April). Hbitos de productividad como programadores. Disponible en Exeal.com.

DEV Community: Henk Sandoval

Cómo hacer Integration Tests con WebApplicationFactory y TDD con .NET

Introducción: La evolución segura en el mundo del software

WebApplicationFactory: Un puente hacia la confianza en el código

Beneficios de WebApplicationFactory

Ejemplo Práctico: Implementación de WebApplicationFactory

Agregar WebApplicationFactory en nuestra solución.

Configurando WebApplicationFactory en nuestra API

Conclusión y próximos pasos

Fuentes

Clean Code: Escribir Código Mantenible

¿Por qué Importa el Código Limpio?

Los Principios del Clean Code [1]

Nombres Significativos [2]

Evitar los "Números Mágicos" [3]

Las Funciones Deben Hacer Una Sola Cosa [4]

Keep it simple, Stupid (KISS) [5]

Don't Repeat Yourself (DRY) [6]

Escribe Pruebas Unitarias [7]

Refactoriza Regularmente [8]

Ejemplo de Refactorización .NET

Conclusión

Fuentes

Los Principios del Clean Code ^[1]

Nombres Significativos ^[2]

Evitar los "Números Mágicos" ^[3]

Las Funciones Deben Hacer Una Sola Cosa ^[4]

Keep it simple, Stupid (KISS) ^[5]

Don't Repeat Yourself (DRY) ^[6]

Escribe Pruebas Unitarias ^[7]

Refactoriza Regularmente ^[8]