Curso de Testing en .NET con xUnit, Moq y Test Server para equipos

Revisión del papel de xUnit como framework principal de pruebas para C#, F# y Visual Basic, con soporte actual para .NET moderno.

Comprensión de xUnit v3 y sus diferencias relevantes frente a v2, incluyendo mejoras de ejecución, descubrimiento y capacidades modernas de plataforma.

Uso de Moq como librería de mocking basada en expresiones lambda y LINQ expression trees, pensada para crear dobles de prueba tipados y mantenibles.

Comprensión de TestServer como servidor en memoria para probar aplicaciones ASP.NET Core sin desplegar un servidor externo.

Uso de WebApplicationFactory para crear clientes de prueba sobre la aplicación real y validar el pipeline HTTP completo.

Diferenciación entre `Microsoft.AspNetCore.Mvc.Testing`, `Microsoft.AspNetCore.TestHost`, xUnit runner, SDK de test y adaptadores de ejecución.

Revisión de la estructura típica de proyectos: aplicación principal, proyecto de pruebas unitarias, proyecto de integración y recursos compartidos.

Configuración de paquetes NuGet, target framework, referencias de proyecto y settings necesarios para ejecutar pruebas en local y CI.

Identificación de incompatibilidades frecuentes: versiones de SDK, paquetes desactualizados, adapters duplicados o configuración de test runner incorrecta.

Preparación de un entorno base con .NET 10, xUnit, Moq, WebApplicationFactory, TestServer y una API ASP.NET Core de laboratorio.

Aplicación de dependency injection para que servicios, repositorios, clientes externos y proveedores de tiempo puedan sustituirse durante pruebas.

Separación entre lógica de negocio, lógica de aplicación, infraestructura y presentación HTTP para reducir tests acoplados a frameworks.

Diseño de interfaces útiles solo cuando aíslan una dependencia real, evitando abstracciones artificiales creadas únicamente para poder mockear.

Uso de clases pequeñas, métodos con intención clara y dependencias explícitas para facilitar pruebas unitarias legibles.

Sustitución de dependencias difíciles de probar como `DateTime.Now`, `Guid.NewGuid`, sistema de archivos, red o variables de entorno por puertos controlables.

Diseño de servicios que devuelven resultados verificables y no dependen de efectos secundarios invisibles.

Control de excepciones, errores de negocio y resultados esperados para que los tests puedan validar flujos sin hacks.

Reducción de lógica dentro de controllers, Minimal APIs, middlewares o handlers HTTP, moviéndola a servicios o casos de uso testables.

Identificación de smell de baja testabilidad: constructores enormes, singletons con estado, métodos estáticos rígidos y acceso directo a infraestructura.

Refactorización de una clase acoplada hacia un diseño con dependencias inyectadas, puertos claros y pruebas unitarias sencillas.

Creación de una estructura de proyectos separando pruebas unitarias, integración, contrato, componentes y pruebas end-to-end cuando sea necesario.

Definición de nombres de proyectos, namespaces, carpetas y clases para que las pruebas sean fáciles de encontrar y mantener.

Establecimiento de convenciones de nombres de tests que expresen comportamiento, condición y resultado esperado sin frases crípticas.

Organización por feature, caso de uso, clase bajo prueba, endpoint, módulo o bounded context según la arquitectura del proyecto.

Configuración de traits, categories, collections o filtros para ejecutar subconjuntos de pruebas por velocidad, criticidad o tipo.

Separación de helpers, builders, fixtures, fakes, test data y utilidades comunes sin crear una librería de tests difícil de entender.

Gestión de archivos de configuración específicos para pruebas, evitando depender de `appsettings.Development.json` o valores de entorno local.

Definición de qué pruebas deben ejecutarse siempre en cada PR y cuáles pueden reservarse para nightly builds o releases.

Preparación de documentación interna para que cualquier desarrollador sepa cómo ejecutar, depurar y añadir pruebas.

Creación de una plantilla corporativa de testing .NET con proyectos, paquetes, carpetas, convenciones y ejemplos mínimos.

Uso de `[Fact]` para pruebas de comportamiento concreto sin parámetros, manteniendo cada test centrado en una expectativa clara.

Uso de `[Theory]` para pruebas parametrizadas donde el mismo comportamiento debe validarse con diferentes datos de entrada.

Aplicación de `InlineData`, `MemberData` y `ClassData` para alimentar escenarios de prueba sin duplicar métodos.

Comprensión del ciclo de vida de una instancia de clase de test en xUnit y cómo afecta a estado compartido, inicialización y aislamiento.

Uso de constructores y `IDisposable` o equivalentes actuales para preparar y limpiar recursos por test.

Creación de fixtures de clase y colección para compartir recursos costosos sin romper aislamiento entre pruebas.

Configuración de ejecución paralela cuando aporta velocidad, y desactivación controlada cuando hay recursos compartidos no paralelizables.

Gestión de salida de test, logs y diagnóstico para entender fallos sin llenar la consola de ruido.

Evitación de tests dependientes del orden de ejecución, del reloj real, del locale, de la zona horaria o de datos externos.

Refactorización de una suite básica de xUnit hacia una estructura profesional con theories, fixtures, helpers y ejecución estable.

Diseño de aserciones que validan comportamiento observable, no detalles internos irrelevantes de la implementación.

Uso correcto de asserts de igualdad, equivalencia, colecciones, excepciones, rangos, tipos, nulos, booleanos y strings.

Evitación de múltiples asserts inconexos en un mismo test cuando dificultan saber qué comportamiento se está validando.

Creación de asserts agrupados cuando un resultado complejo debe validarse como una unidad coherente.

Validación de excepciones con intención, comprobando tipo, mensaje relevante, propiedades y condiciones que provocan el error.

Uso de aserciones sobre resultados de dominio, errores de negocio, códigos HTTP, payloads, cabeceras y side effects controlados.

Creación de helpers de aserción propios para evitar duplicación y mejorar legibilidad en objetos complejos.

Identificación de asserts demasiado débiles que permiten que el test pase aunque el comportamiento esté roto.

Diseño de mensajes de fallo útiles para que un test roto explique el problema sin obligar a depurar durante media hora.

Revisión de tests existentes para mejorar nombres, asserts, estructura Arrange-Act-Assert y precisión de diagnóstico.

Diseño de datos de prueba mínimos, expresivos y ajustados al escenario, evitando objetos gigantes llenos de valores irrelevantes.

Creación de Test Data Builders para construir entidades, comandos, DTOs, usuarios, permisos y respuestas externas con defaults razonables.

Uso de Object Mother con criterio cuando existen escenarios de negocio estables y compartidos por muchas pruebas.

Separación entre datos válidos por defecto y variaciones explícitas que hacen que cada test comunique su intención.

Evitación de fixtures globales opacas que esconden demasiados datos y hacen que los tests sean difíciles de leer.

Generación de datos variables solo cuando aporta valor, evitando aleatoriedad que vuelve los fallos imposibles de reproducir.

Creación de escenarios de negocio completos para validar reglas complejas sin depender de base de datos real.

Gestión de fechas, zonas horarias, identificadores y cultura para que las pruebas sean deterministas en cualquier máquina.

Diseño de datasets de integración que no se pisan entre tests paralelos ni dependen de orden de ejecución.

Construcción de una librería de builders y escenarios para el proyecto de laboratorio, manteniendo claridad y bajo acoplamiento.

Diferenciación entre dummy, fake, stub, spy y mock para elegir el doble de prueba adecuado en cada situación.

Creación de mocks de interfaces y clases compatibles, configurando retornos, excepciones, callbacks y comportamientos esperados.

Uso de `Setup` para definir respuestas ante métodos, propiedades, argumentos concretos o predicados.

Uso de `Returns`, `ReturnsAsync`, `Throws`, `ThrowsAsync` y callbacks para representar dependencias en distintos escenarios.

Verificación de interacciones con `Verify`, `Times`, argumentos esperados y ausencia de llamadas no deseadas.

Aplicación de `MockBehavior.Loose` y `MockBehavior.Strict` según el tipo de prueba y el nivel de contrato que se quiere proteger.

Evitación de mocks sobre objetos que podrían probarse con implementaciones reales simples, fakes o in-memory.

Identificación de tests demasiado acoplados a la implementación por verificar cada llamada interna sin necesidad.

Diseño de mocks que reflejan contratos de colaboración, no detalles accidentales del método actual.

Refactorización de una prueba frágil con Moq hacia una prueba más clara, centrada en resultado e interacción relevante.

Uso de `It.Is`, `It.IsAny`, `It.IsInRange`, `It.IsRegex` y predicados personalizados para validar argumentos con precisión.

Captura de argumentos mediante callbacks para comprobar valores construidos internamente sin exponer detalles innecesarios en producción.

Configuración de secuencias de respuestas para simular reintentos, fallos temporales, dependencia degradada o cambios de estado.

Simulación de eventos, callbacks y notificaciones cuando el servicio bajo prueba reacciona a señales externas.

Configuración de propiedades, getters, setters y comportamiento de objetos con estado controlado.

Verificación de orden cuando el contrato realmente lo exige, evitando imponer orden artificial en colaboraciones que no lo necesitan.

Mocking de métodos protegidos solo cuando no existe una alternativa de diseño mejor y el coste de refactorización no compensa.

Diseño de mocks para métodos genéricos, sobrecargas, expresiones, delegates y APIs con parámetros opcionales.

Identificación de limitaciones de Moq ante métodos estáticos, extensiones, clases selladas o dependencias no virtuales.

Creación de una guía interna para usar Moq sin convertir las pruebas en duplicados rígidos de la implementación.

Escritura de pruebas asíncronas correctas con `async Task`, evitando `async void`, bloqueos con `.Result` o `.Wait()` y deadlocks.

Validación de métodos que devuelven `Task`, `ValueTask`, `IAsyncEnumerable` o resultados asíncronos desde servicios y repositorios.

Simulación de dependencias asíncronas con Moq, incluyendo respuestas correctas, excepciones y latencia controlada.

Prueba de `CancellationToken` para confirmar que operaciones largas, llamadas HTTP, consultas y workers respetan cancelación.

Diseño de tests para timeouts y reintentos sin esperar tiempos reales excesivos ni ralentizar la suite.

Validación de condiciones de carrera, operaciones concurrentes, locks, idempotencia y actualización simultánea de recursos.

Control de reloj y temporizadores mediante abstracciones para evitar pruebas lentas o no deterministas.

Uso de barreras, señales o fakes controlados para reproducir escenarios concurrentes de forma fiable.

Detección de errores comunes en pruebas asíncronas que pasan falsamente porque no esperan realmente la operación.

Construcción de una suite de pruebas sobre un servicio asíncrono con cancelación, retry, timeout y concurrencia controlada.

Prueba de entidades, value objects, agregados y políticas de negocio sin base de datos, APIs externas ni frameworks innecesarios.

Validación de invariantes del dominio ante escenarios válidos, inválidos, extremos y cambios de estado sucesivos.

Creación de pruebas que documentan reglas de negocio con ejemplos claros, lenguaje ubicuo y nombres entendibles por perfiles técnicos.

Uso de builders para montar escenarios de dominio sin duplicar inicialización ni ocultar condiciones importantes.

Comprobación de errores de negocio, estados rechazados, transiciones prohibidas y mensajes relevantes.

Validación de eventos de dominio generados por operaciones importantes, sin acoplar la prueba al mecanismo de publicación.

Prueba de value objects con igualdad, normalización, validación, inmutabilidad y operaciones propias.

Evitación de mocks dentro del dominio puro cuando se puede probar comportamiento directamente.

Identificación de lógica de negocio escondida en controladores, servicios o repositorios que debería moverse a dominio.

Refactorización de una regla dispersa hacia un modelo de dominio cubierto por pruebas unitarias expresivas.

Prueba de application services, command handlers, query handlers o casos de uso como orquestadores de dominio, puertos y transacciones.

Aislamiento de dependencias externas mediante Moq cuando el objetivo es validar coordinación y decisiones del caso de uso.

Uso de fakes o repositorios in-memory cuando aportan más claridad que un mock lleno de setups complejos.

Validación de flujos de éxito, errores de negocio, permisos denegados, dependencias fallidas y datos no encontrados.

Comprobación de interacciones relevantes: persistencia de cambios, publicación de eventos, llamada a servicios externos o auditoría.

Separación entre pruebas unitarias del caso de uso y pruebas de integración que validan infraestructura real.

Diseño de resultados tipados para facilitar pruebas de errores esperados sin depender de excepciones genéricas.

Prueba de transacciones, idempotencia, comportamiento ante duplicados y efectos secundarios controlados.

Creación de fixtures y builders para comandos, usuarios, permisos, entidades existentes y respuestas de puertos.

Implementación de pruebas completas sobre un caso de uso con Moq, asserts de resultado, verifies relevantes y escenarios negativos.

Diferenciación entre probar lógica de dominio, queries, mappings EF Core, migraciones y comportamiento real de base de datos.

Evaluación de cuándo usar provider in-memory, SQLite en memoria, base real en contenedor o doble de repositorio.

Validación de consultas LINQ, filtros, paginación, ordenación, includes, proyecciones y permisos sobre datos.

Prueba de mappings EF Core, conversiones, owned types, índices, constraints y relaciones críticas.

Detección de problemas que el provider in-memory no reproduce, como SQL real, constraints, transacciones o diferencias de traducción LINQ.

Uso de transacciones, limpieza por test, bases efímeras o schemas aislados para evitar contaminación entre pruebas.

Creación de datos de persistencia mediante builders o seeds controlados, evitando dumps enormes difíciles de mantener.

Validación de migraciones importantes antes de release, comprobando pérdida de datos, defaults, índices y compatibilidad.

Medición del coste de pruebas de integración con base de datos para decidir qué debe ejecutarse en PR y qué en pipeline profundo.

Construcción de una suite de persistencia para un repositorio EF Core con consultas, mappings y errores realistas.

Comprensión de TestServer como servidor en memoria que permite ejecutar el pipeline ASP.NET Core completo dentro del proceso de pruebas.

Uso de `WebApplicationFactory<TEntryPoint>` para crear una instancia de la aplicación bajo prueba con configuración controlada.

Creación de `HttpClient` de prueba para llamar endpoints como lo haría un consumidor real, validando routing, middleware, filtros y respuestas.

Diferenciación entre pruebas unitarias de controller o handler y pruebas de integración que recorren el pipeline HTTP.

Configuración de `Program` como entry point de la aplicación moderna con minimal hosting.

Organización de fixtures de integración para compartir factory, cliente HTTP, configuración y recursos costosos.

Control del entorno de ejecución mediante `ASPNETCORE_ENVIRONMENT`, configuración de test y sustitución de servicios.

Análisis de errores frecuentes: entry point inaccesible, Program interno, configuración incorrecta, servicios duplicados o base de datos real usada por accidente.

Diseño de pruebas de integración rápidas y deterministas que no dependen de servicios externos no controlados.

Construcción de una primera suite de TestServer sobre una API ASP.NET Core con endpoints reales y asserts HTTP completos.

Personalización de `WebApplicationFactory` para sustituir servicios registrados en producción por fakes, mocks o implementaciones de test.

Uso de `ConfigureWebHost` y configuración específica para modificar DI, settings, autenticación, base de datos y servicios externos.

Separación entre factory base, factories especializadas y métodos helper para no duplicar setup en cada clase de test.

Sustitución de `DbContext` real por base de datos de prueba, contenedor, SQLite o instancia aislada.

Inyección de mocks de servicios externos cuando se quiere validar pipeline HTTP sin llamar proveedores reales.

Configuración de headers, cookies, usuario autenticado, claims, tokens o handlers de autenticación de prueba.

Control de datos iniciales por test, por clase o por colección, evitando contaminación entre escenarios.

Personalización de `HttpClient` con base address, timeouts, redirects, cookies y comportamiento de validación.

Gestión de logs de la aplicación durante pruebas para diagnosticar errores de integración sin ruido excesivo.

Creación de una factory corporativa reutilizable para APIs ASP.NET Core con seguridad, datos, mocks y configuración de test.

Validación de endpoints REST completos mediante llamadas HTTP reales sobre TestServer y `HttpClient`.

Comprobación de códigos de estado, cabeceras, media types, serialización JSON, payloads, errores y estructura de respuesta.

Prueba de endpoints GET, POST, PUT, PATCH y DELETE con datos válidos, inválidos, incompletos y conflictivos.

Validación de errores de modelo, `ProblemDetails`, errores de negocio, `404`, `409`, `401`, `403` y errores inesperados controlados.

Creación de helpers para serializar requests, deserializar responses y comprobar contratos sin repetir código en cada prueba.

Prueba de paginación, filtros, ordenación, búsqueda, parámetros de ruta y query string.

Validación de idempotencia, concurrencia, duplicados, cambios de estado y efectos secundarios observables.

Control de contenido sensible en respuestas, asegurando que no se devuelven campos internos, secretos o datos no autorizados.

Comparación entre pruebas de API a nivel de TestServer y pruebas de contrato más específicas.

Construcción de una batería de pruebas sobre una API de gestión completa con flujos de alta, edición, consulta, error y eliminación.

Prueba de Minimal APIs desde TestServer validando routing, binding, validación, filtros, DI y respuestas tipadas.

Prueba de controllers ASP.NET Core con enfoque de integración, evitando tests unitarios de controllers que solo duplican el framework.

Validación de endpoint filters, action filters, exception filters y middlewares que transforman o bloquean peticiones.

Comprobación de model binding, route constraints, query parameters, body JSON y errores de formato.

Prueba de endpoints agrupados, versionados o protegidos por políticas de autorización.

Validación de respuestas generadas por `Results`, `TypedResults`, `ActionResult` o patrones equivalentes.

Diseño de escenarios para comprobar que los endpoints delegan correctamente en casos de uso y traducen resultados a HTTP.

Evitación de pruebas que validan detalles internos del framework en lugar de comportamiento propio de la aplicación.

Creación de fixtures compartidas para endpoints con configuración, datos y autenticación común.

Implementación de una suite de pruebas para Minimal APIs con filtros, errores, autorización y serialización JSON.

Configuración de autenticación de prueba para simular usuarios autenticados sin depender de un proveedor real de identidad.

Creación de usuarios con claims, roles, permisos, tenant, scopes y atributos relevantes para escenarios de autorización.

Validación de respuestas `401 Unauthorized` cuando falta autenticación y `403 Forbidden` cuando el usuario no tiene permisos.

Prueba de policies de ASP.NET Core sobre endpoints, controllers, Minimal APIs y recursos concretos.

Validación de autorización por recurso cuando el permiso depende del propietario, estado, tenant o relación con la entidad.

Comprobación de que ocultar acciones en UI no sustituye controles server-side en APIs y handlers.

Prueba de antiforgery, cookies, headers, CORS, tokens, expiración y flujos protegidos cuando aplican al proyecto.

Verificación de que datos sensibles no aparecen en respuestas, errores, logs de test ni payloads no autorizados.

Creación de tests de regresión para bugs de seguridad detectados en producción o auditorías.

Construcción de una matriz de pruebas de permisos por rol, recurso, operación y endpoint crítico.

Prueba de middlewares personalizados mediante TestServer para validar orden, headers, short-circuit, logs y respuestas.

Validación del middleware global de excepciones, comprobando que errores inesperados se traducen a respuestas seguras y consistentes.

Comprobación de correlation IDs, request IDs, cabeceras de seguridad, culture, tenant resolution y contexto de usuario.

Prueba de rate limiting, compresión, CORS, autenticación, autorización y middlewares de auditoría cuando forman parte del pipeline.

Validación de que errores internos no exponen stack traces, nombres de tablas, secretos, rutas internas o detalles sensibles.

Diseño de tests para peticiones malformadas, content types incorrectos, cuerpos inválidos y métodos HTTP no permitidos.

Control de logs emitidos por middleware para confirmar que se registra información útil sin datos sensibles.

Prueba de comportamiento ante rutas no encontradas, endpoints no autorizados y errores de validación de entrada.

Evitación de tests demasiado dependientes del orden interno cuando basta validar el comportamiento observable.

Implementación de pruebas sobre un pipeline ASP.NET Core con exception handling, correlation ID, seguridad y auditoría.

Diseño de pruebas para servicios que consumen APIs externas sin llamar proveedores reales en unitarias ni builds de CI.

Uso de Moq sobre abstracciones propias cuando el objetivo es validar lógica de aplicación que depende de un servicio externo.

Simulación de `HttpMessageHandler` o clientes tipados para controlar respuestas HTTP, errores, timeouts y payloads.

Validación de serialización, deserialización, cabeceras, autenticación, retries, timeouts y errores devueltos por APIs externas.

Creación de fakes HTTP o servidores de prueba cuando se quiere validar contrato realista con menos acoplamiento a mocks.

Diseño de escenarios de fallo: `500`, `429`, timeout, respuesta inválida, token caducado, throttling y datos incompletos.

Prueba de políticas de resiliencia para clientes externos: retry, circuit breaker, fallback, bulkhead y cancelación.

Verificación de que no se registran tokens, payloads sensibles o datos personales en logs durante errores externos.

Separación entre pruebas de integración internas y pruebas contractuales con proveedores o sandboxes externos.

Construcción de una suite para un cliente HTTP corporativo con éxito, errores, reintentos, timeout y mapeo de respuestas.

Prueba de `BackgroundService`, hosted services, jobs programados y consumidores asíncronos sin esperar tiempos reales largos.

Diseño de workers con dependencias inyectables, cancelación controlada y unidades de trabajo testables.

Simulación de colas, mensajes, timers, dependencias externas y errores transitorios mediante fakes o mocks.

Validación de procesamiento correcto, reintentos, errores permanentes, dead letter handling y logging útil.

Prueba de shutdown graceful usando `CancellationToken` para confirmar que el servicio no deja operaciones a medias.

Control de loops infinitos mediante abstracciones de scheduler, canales, fuentes de mensajes o disparadores manuales en test.

Validación de idempotencia cuando el worker puede recibir el mismo mensaje varias veces.

Comprobación de métricas o eventos emitidos por el worker para observabilidad operativa.

Evitación de pruebas lentas basadas en `Task.Delay` cuando puede usarse una abstracción controlable.

Construcción de pruebas de un worker .NET con procesamiento, cancelación, errores, retries y efectos observables.

Prueba de productores de eventos validando tipo, payload, metadata, versionado, correlation ID y datos mínimos necesarios.

Validación de consumidores con eventos válidos, inválidos, duplicados, antiguos, desordenados y de versiones previas.

Uso de fakes, brokers en contenedor o Testcontainers según el nivel de integración que se quiera comprobar.

Comprobación de idempotencia para evitar efectos secundarios duplicados ante reentrega de mensajes.

Validación de errores transitorios, errores permanentes, reintentos, DLQ y registro de fallos.

Prueba de Outbox e Inbox cuando el sistema necesita publicación fiable y deduplicación.

Creación de tests de contrato para eventos publicados y consumidos por otros servicios.

Control de serialización y compatibilidad de schemas para evitar romper consumidores existentes.

Medición de lag, mensajes pendientes y errores como parte de pruebas de integración cuando aplica.

Construcción de un escenario event-driven de laboratorio con productor, consumidor, broker, errores y pruebas automatizadas.

Validación de reglas de entrada con datos incompletos, formatos incorrectos, longitudes, rangos, duplicados y combinaciones inválidas.

Separación entre errores de validación sintáctica, errores de negocio, conflictos de estado y fallos técnicos inesperados.

Comprobación de respuestas `ProblemDetails` con status, title, detail controlado, trace ID, errores de campo y extensiones permitidas.

Evitación de mensajes técnicos excesivos que exponen detalles internos o dificultan interpretación por consumidores.

Prueba de localización o mensajes por cultura cuando la aplicación ofrece respuestas en varios idiomas.

Validación de consistencia de errores entre endpoints para que los consumidores puedan manejar fallos de forma homogénea.

Creación de builders de requests inválidas para cubrir escenarios sin duplicar JSON manualmente.

Prueba de errores concurrentes, estados no modificables, operaciones repetidas y conflictos de versión.

Integración de errores de dominio con respuestas HTTP sin acoplar entidades a ASP.NET Core.

Construcción de una suite de errores completa sobre endpoints críticos y casos de uso de negocio.

Diseño de pruebas para asegurar que los contratos HTTP publicados no cambian accidentalmente entre versiones.

Validación de OpenAPI generado por la aplicación, comprobando rutas, métodos, schemas, errores, seguridad y media types.

Comparación de contratos esperados frente a contratos generados para detectar breaking changes antes de release.

Prueba de compatibilidad hacia atrás cuando se añaden campos, se deprecian rutas o cambia la semántica de una respuesta.

Validación de consumidores simulados que esperan formatos concretos de respuesta, errores y cabeceras.

Separación entre pruebas de contrato internas, contract testing consumidor-proveedor y pruebas de integración completas.

Creación de snapshots controlados de contrato, evitando snapshots enormes que nadie revisa realmente.

Uso de CI/CD para bloquear cambios incompatibles en endpoints críticos.

Documentación de reglas de versionado y compatibilidad para APIs empresariales.

Construcción de una suite que valida OpenAPI y detecta cambios de contrato en una API ASP.NET Core.

Interpretación de cobertura como señal incompleta, útil para detectar zonas sin pruebas pero insuficiente para garantizar calidad.

Diferenciación entre cobertura de líneas, ramas, métodos, condiciones y reglas de negocio críticas.

Identificación de tests que aumentan cobertura sin proteger comportamiento relevante.

Uso de mutation testing cuando se quiere evaluar si la suite detecta cambios defectuosos en la lógica.

Priorización de cobertura en dominio, casos de uso críticos, seguridad, contratos, errores y flujos de alto riesgo.

Creación de quality gates realistas que no bloquean por porcentajes arbitrarios sin contexto.

Análisis de zonas de baja cobertura con riesgo alto, frecuencia de cambio o historial de bugs.

Mejora de tests existentes antes de escribir nuevas pruebas redundantes.

Creación de informes de cobertura legibles para desarrollo, QA y responsables técnicos.

Definición de una política de cobertura útil para equipos .NET basada en riesgo, criticidad y valor de regresión.

Identificación de causas frecuentes de pruebas flaky: orden de ejecución, reloj real, datos compartidos, red, concurrencia, paralelismo y timeouts.

Diseño de pruebas deterministas que controlan tiempo, cultura, zona horaria, identificadores, aleatoriedad y estado externo.

Separación de pruebas rápidas y lentas para que el feedback de PR no se convierta en un cuello de botella.

Uso de retries en pipelines solo como medida temporal y visible, no como forma de ocultar problemas reales.

Limpieza de recursos entre tests: bases de datos, ficheros, colas, caches, usuarios, tokens y configuración.

Control de paralelización con collections, fixtures o aislamiento cuando existen recursos compartidos.

Análisis de tests lentos para decidir si deben optimizarse, moverse a otro pipeline o reemplazarse por pruebas más específicas.

Registro de fallos intermitentes con evidencia, frecuencia, causa probable y plan de corrección.

Creación de dashboards o informes de estabilidad de pruebas en CI/CD.

Refactorización de una suite flaky hacia ejecución más fiable, rápida y reproducible.

Integración de pruebas xUnit en pipelines de GitHub Actions, Azure Pipelines, GitLab CI, Jenkins o plataforma corporativa equivalente.

Ejecución separada de unitarias, integración, contrato, seguridad y pruebas lentas según fase del pipeline.

Publicación de resultados de test, cobertura, logs, artefactos y diagnósticos para facilitar revisión de fallos.

Configuración de quality gates sobre tests obligatorios, cobertura crítica, contratos, seguridad y migraciones.

Uso de filtros por traits o categorías para controlar qué se ejecuta en pull request, merge, nightly o release.

Gestión de variables, secretos, cadenas de conexión y servicios auxiliares de prueba dentro del pipeline.

Preparación de bases de datos, contenedores, TestServer y recursos efímeros durante ejecución CI.

Optimización de tiempos mediante paralelización, cache de dependencias, separación de suites y eliminación de tests redundantes.

Diagnóstico de fallos que ocurren solo en CI por diferencias de sistema operativo, ruta, permisos, cultura o variables.

Construcción de un pipeline completo de calidad para una API .NET con xUnit, Moq, TestServer, cobertura e informes.

Creación de pruebas automatizadas para accesos no autorizados, roles incorrectos, claims ausentes y permisos por recurso.

Validación de que endpoints críticos no devuelven datos sensibles, campos internos, tokens, secretos o información de otros tenants.

Prueba de entradas maliciosas básicas: payloads excesivos, formatos inesperados, rutas manipuladas y parámetros inválidos.

Comprobación de que errores internos no exponen stack traces, SQL, rutas de servidor, nombres internos o detalles de infraestructura.

Validación de cabeceras de seguridad, CORS, cookies, antiforgery y políticas de autenticación cuando forman parte del sistema.

Creación de tests de regresión para vulnerabilidades corregidas, asegurando que el mismo fallo no vuelve a introducirse.

Integración de secret scanning, dependency scanning o análisis estático como complemento a las pruebas funcionales.

Prueba de límites de rate limiting, bloqueo de operaciones, permisos administrativos y acciones sensibles.

Documentación de escenarios de seguridad cubiertos y huecos que requieren pruebas manuales o herramientas especializadas.

Creación de una suite AppSec básica para APIs ASP.NET Core dentro del pipeline de calidad.

Diagnóstico de aplicaciones legacy con baja cobertura, dependencias estáticas, servicios acoplados y lógica en controladores o repositorios.

Creación de pruebas de caracterización para capturar comportamiento actual antes de refactorizar.

Identificación de seams donde introducir interfaces, adaptadores, wrappers o fakes sin reescribir toda la aplicación.

Priorización de pruebas en zonas de alto riesgo: bugs frecuentes, reglas críticas, cambios recurrentes o deuda acumulada.

Refactorización incremental guiada por tests, moviendo lógica hacia servicios, dominio o casos de uso testables.

Uso de Moq solo donde ayuda a aislar dependencias, no como parche permanente para un diseño difícil de probar.

Introducción de TestServer para cubrir endpoints críticos cuando no existe confianza en pruebas unitarias aisladas.

Creación de golden master tests cuando el comportamiento es complejo y todavía no se entiende completamente.

Medición de avance por reducción de deuda, aumento de pruebas útiles y menor miedo a modificar código existente.

Diseño de un plan de testing para legacy con fases, quick wins, zonas críticas y criterios de salida.

Definición de criterios de revisión para comprobar si un cambio incluye pruebas proporcionales al riesgo que introduce.

Identificación de pruebas insuficientes: solo happy path, asserts débiles, mocks excesivos, ausencia de errores y falta de permisos.

Revisión de si las pruebas cubren reglas de negocio, integración, contrato, seguridad y regresiones vinculadas al cambio.

Evaluación de la legibilidad de tests: nombres, Arrange-Act-Assert, builders, datos mínimos y mensajes de fallo.

Detección de tests acoplados a detalles internos que romperán con cualquier refactorización legítima.

Revisión de uso correcto de Moq, evitando verifies innecesarios, setups duplicados y mocks sobre estructuras que deberían ser reales.

Validación de pruebas de integración con TestServer cuando el cambio afecta a routing, middleware, seguridad o contrato HTTP.

Comprobación de que nuevas dependencias de infraestructura tienen una estrategia clara de sustitución en test.

Uso de checklist de testing en pull requests para estandarizar expectativas del equipo.

Creación de comentarios de revisión útiles que expliquen qué escenario falta y por qué importa.

Diseño de pruebas que resisten refactorizaciones internas porque validan comportamiento observable y no estructura accidental.

Eliminación de duplicación mediante builders, helpers y fixtures sin ocultar la intención principal del test.

Revisión periódica de pruebas obsoletas, redundantes, lentas, flaky o desconectadas de requisitos actuales.

Gestión de cambios de arquitectura para mantener la suite alineada con nuevos módulos, servicios o boundaries.

Creación de documentación viva sobre cómo escribir tests en el proyecto y qué convenciones deben respetarse.

Control de deuda de testing mediante issues, métricas, revisión de PR y refactorización de tests.

Separación entre helpers útiles y frameworks internos de testing demasiado complejos que nadie entiende.

Evaluación del coste de mantenimiento de pruebas frente al riesgo que cubren.

Preparación de sesiones de mejora de suite: limpiar tests lentos, mejorar aserciones, reducir mocks y estabilizar CI.

Creación de un modelo de ownership de pruebas para que no sean responsabilidad difusa de “QA” o “el pipeline”.

Definir una aplicación ASP.NET Core de laboratorio con dominio, servicios, EF Core, endpoints, autenticación, integraciones externas y errores controlados.

Diseñar estrategia de testing completa con unitarias, integración, contrato, seguridad, persistencia y regresión.

Implementar pruebas de dominio con xUnit, builders, aserciones expresivas y escenarios de negocio críticos.

Implementar pruebas de servicios de aplicación con Moq, validando resultados, errores, interacciones relevantes y dependencias simuladas.

Configurar WebApplicationFactory y TestServer para ejecutar pruebas de API con HttpClient, datos de prueba y configuración específica.

Validar endpoints con respuestas HTTP, ProblemDetails, serialización JSON, autorización, permisos y errores de validación.

Probar persistencia EF Core con base de datos de prueba, mappings, queries, migraciones o datos aislados por escenario.

Incorporar pruebas de integración externas mediante fakes, mocks HTTP o servicios en contenedor según el caso.

Integrar la suite en CI/CD con filtros, cobertura útil, informes, quality gates y diagnóstico de fallos.

Presentar el proyecto con estrategia de testing, estructura, decisiones, cobertura crítica, riesgos cubiertos y plan de mejora continua.