Curso de Testing en .NET con TUnit para tu equipo técnico

Comprensión de TUnit como framework de testing moderno para C# y .NET, con soporte para pruebas unitarias, integración, aceptación y otros tipos de validación.

Revisión de su arquitectura basada en Microsoft.Testing.Platform, generación de código fuente, optimización en compilación y compatibilidad AOT.

Comparación conceptual con xUnit, NUnit y MSTest, identificando cambios en descubrimiento, ejecución, paralelización, datos, assertions y modelo mental.

Análisis de por qué la ejecución paralela por defecto obliga a diseñar pruebas independientes, recursos aislados y datos sin interferencias.

Revisión de paquetes principales del ecosistema: TUnit, TUnit.Assertions, TUnit.AspNetCore, integraciones y extensiones de infraestructura.

Identificación de capacidades clave: `[Test]`, argumentos, data sources, matrix tests, hooks, contexts, filters, retries, timeouts y reporting.

Comprensión de que las assertions de TUnit son asíncronas y deben esperarse con `await`, un punto crítico para evitar falsos positivos.

Diferenciación entre pruebas rápidas de lógica pura y pruebas que requieren servidor de test, contenedores, base de datos, colas o servicios auxiliares.

Evaluación de cuándo adoptar TUnit en un proyecto nuevo y cuándo migrar gradualmente desde un framework existente.

Preparación de criterios internos para elegir TUnit: rendimiento, paralelización, experiencia de desarrollador, compatibilidad, madurez del equipo y necesidades de CI/CD.

Creación de un proyecto de pruebas TUnit desde cero, instalando paquetes NuGet necesarios y validando ejecución con `dotnet test` o el runner compatible.

Organización de proyectos de test por tipo: unitarios, integración, API, contrato, infraestructura y pruebas end-to-end cuando el proyecto lo justifica.

Configuración de `TargetFramework`, referencias de proyecto, paquetes, analyzers, warnings y reglas de compilación para detectar problemas temprano.

Preparación de una solución .NET con proyecto productivo, proyecto de dominio, API ASP.NET Core, proyecto de tests unitarios y proyecto de integración.

Definición de convenciones de nombres para clases de test, métodos, carpetas, namespaces y recursos compartidos.

Separación de helpers, builders, data sources, fixtures, fakes y utilidades comunes para evitar duplicación sin esconder la intención de cada test.

Configuración de settings específicos de pruebas, evitando depender de valores locales, entornos personales o `appsettings.Development.json`.

Validación de la ejecución local desde IDE, terminal y pipeline, detectando diferencias de entorno antes de que generen fallos intermitentes.

Preparación de scripts de arranque para que cualquier desarrollador pueda restaurar, compilar y ejecutar la suite completa sin conocimiento tribal.

Creación de una plantilla corporativa base de TUnit con estructura, paquetes, documentación mínima, convenciones y ejemplos.

Escritura de pruebas básicas con `[Test]`, cuidando que cada test valide un comportamiento concreto y no una mezcla de casos sin relación.

Aplicación del patrón Arrange-Act-Assert para separar preparación, acción y verificación de forma legible y mantenible.

Creación de nombres de test que expresan condición, acción y resultado esperado sin caer en frases crípticas o demasiado largas.

Validación de resultados de métodos síncronos, asíncronos, servicios de dominio, funciones puras y pequeños casos de uso.

Diseño de pruebas independientes entre sí, sin depender del orden de ejecución, estado de instancia o datos que dejó otro test.

Comprensión del comportamiento de instanciación de clases de test en TUnit y su impacto en aislamiento, recursos compartidos y estado mutable.

Evitación de estado compartido accidental en campos de instancia, colecciones estáticas, singletons de prueba o datos inicializados de forma global.

Uso de datos mínimos en cada test para que el lector entienda qué condición provoca el resultado esperado.

Revisión de errores frecuentes: asserts olvidados, assertions sin `await`, tests que pasan sin comprobar nada y pruebas que validan implementación interna.

Refactorización de una primera batería de pruebas simples hacia una suite con nombres, estructura y aserciones expresivas.

Uso correcto de `Assert.That(...)` como punto de entrada para assertions fluidas, legibles y fuertemente tipadas.

Aplicación de assertions de igualdad, comparación, nulos, booleanos, strings, colecciones, excepciones, tipos y operaciones asíncronas.

Interiorización de que las assertions de TUnit deben ejecutarse con `await`, porque una assertion no esperada puede no comprobar el resultado.

Diseño de assertions que validan comportamiento observable, no detalles accidentales de implementación que romperán con cualquier refactor legítimo.

Uso de encadenamientos de assertions cuando varias condiciones forman parte de una misma expectativa coherente.

Aplicación de assertions múltiples cuando se necesita obtener varios fallos relevantes en una sola ejecución del escenario.

Creación de assertions sobre objetos complejos usando member assertions, predicados, colecciones, equivalencia y condiciones personalizadas.

Validación de excepciones asíncronas, timeouts, operaciones que deben completarse dentro de un plazo y errores esperados.

Evitación de asserts débiles como “no es null” cuando el comportamiento real exige validar estado, contenido, reglas y efectos observables.

Construcción de una guía de assertions TUnit para que el equipo escriba pruebas consistentes, claras y útiles en revisión.

Uso de `[Arguments]` para validar el mismo comportamiento con varios conjuntos de entrada y salida sin duplicar métodos de test.

Diseño de tests parametrizados que siguen siendo legibles, con datos comprensibles y nombres que no se convierten en combinaciones imposibles de diagnosticar.

Aplicación de data-driven testing para reglas de negocio con valores frontera, equivalencias, estados válidos, estados inválidos y combinaciones relevantes.

Uso de matrix tests cuando se necesita validar combinaciones de parámetros de forma sistemática sin escribir manualmente todos los casos.

Creación de custom data sources cuando los datos vienen de builders, catálogos internos, escenarios de negocio o generadores controlados.

Separación entre datos de test estables y datos generados dinámicamente, evitando aleatoriedad no reproducible.

Control de tamaño de matrices para que una prueba parametrizada no dispare miles de casos sin valor proporcional.

Validación de mensajes, códigos de error, reglas de formato, conversiones, cálculos y políticas usando datos representativos.

Documentación de escenarios mediante data sources con nombres de negocio, no solo arrays de números o strings sin contexto.

Construcción de una batería de tests parametrizados para una política empresarial compleja, combinando argumentos, data sources y assertions precisas.

Uso de lifecycle hooks para preparar y limpiar recursos antes o después de pruebas, clases, ensamblados o sesiones de test.

Diferenciación entre setup por test, setup compartido, inicialización global y recursos costosos que no conviene reconstruir continuamente.

Diseño de hooks asíncronos para crear bases temporales, colas, ficheros, usuarios de prueba, datos sintéticos o contenedores.

Limpieza segura de recursos incluso cuando una prueba falla, evitando contaminación de ejecuciones posteriores.

Evitación de setup oculto que hace que el test sea difícil de leer porque las condiciones importantes no están visibles.

Uso de hooks para inicializar infraestructura compartida sin romper el aislamiento por test.

Control de orden y dependencias de inicialización cuando existe infraestructura realista: contenedores, API, broker, cache o base de datos.

Diagnóstico de errores de lifecycle cuando una configuración se ejecuta demasiado pronto, demasiado tarde o en un contexto equivocado.

Separación entre preparación funcional del escenario y preparación técnica de infraestructura.

Creación de una estrategia de lifecycle TUnit para proyectos con pruebas unitarias rápidas y pruebas de integración con recursos pesados.

Comprensión de que TUnit impulsa la ejecución concurrente de pruebas y que esto exige aislar recursos, datos y efectos secundarios.

Identificación de recursos que suelen causar interferencias: tablas compartidas, colas, claves Redis, ficheros, usuarios, buckets, puertos y estado estático.

Uso de `[NotInParallel]` solo cuando la prueba realmente no puede aislarse, evitando convertir toda la suite en secuencial por comodidad.

Diseño de nombres únicos, prefijos por test, schemas temporales, bases efímeras o claves de aislamiento para recursos compartidos.

Separación de infraestructura compartida y datos por prueba para aprovechar rendimiento sin sacrificar determinismo.

Diagnóstico de flaky tests provocados por paralelización: fallos intermitentes, datos cruzados, recursos borrados por otro test o orden implícito.

Control de estado estático, singletons, caches y servicios compartidos que pueden contaminar ejecuciones en paralelo.

Preparación de pruebas repetibles cuando se quiere validar estabilidad de escenarios propensos a carreras o intermitencias.

Definición de criterios para desactivar paralelismo en casos excepcionales, documentando la razón y el plan de corrección.

Refactorización de una suite con interferencias hacia ejecución paralela segura, con aislamiento de datos y limpieza verificable.

Uso de `TestContext` para acceder a información del test actual, salida, identificadores, metadatos y contexto de ejecución.

Creación de logs de test útiles para diagnosticar fallos sin llenar la salida de ruido irrelevante.

Separación entre logs del test y logs de la aplicación bajo prueba, manteniendo correlación clara entre petición, servicio y escenario.

Diseño de mensajes de diagnóstico que expliquen datos de entrada, usuario simulado, recurso aislado, respuesta HTTP y causa probable.

Uso de identificadores únicos por prueba para rastrear recursos creados, peticiones ejecutadas y datos persistidos.

Integración de logging de ASP.NET Core con pruebas de integración para ver errores reales de servidor asociados al test que los provocó.

Captura de artefactos de diagnóstico: respuestas HTTP, payloads anonimizados, logs, screenshots, trazas o archivos generados.

Prevención de filtrado de datos sensibles en output de test, especialmente cuando se trabaja con autenticación, tokens o datos personales.

Revisión de fallos en CI usando salida estructurada, logs correlados y nombres de test suficientemente informativos.

Creación de una política de diagnóstico de pruebas para que los fallos se puedan entender sin reproducirlos localmente durante horas.

Uso de dependency injection para construir servicios, casos de uso, repositorios, clientes externos, validadores y objetos de infraestructura dentro de tests.

Configuración de contenedores de DI específicos para pruebas unitarias, integración o componente, evitando copiar el contenedor productivo sin control.

Sustitución de dependencias reales por fakes, stubs, mocks o implementaciones en memoria cuando el objetivo de la prueba lo requiere.

Gestión de lifetimes en pruebas para evitar singletons con estado, scoped services mal reutilizados o recursos que se liberan demasiado pronto.

Inyección de servicios de tiempo, generación de IDs, usuarios actuales, configuración, clientes HTTP y repositorios de prueba.

Creación de módulos de DI reutilizables para escenarios comunes sin ocultar condiciones relevantes de cada test.

Validación de configuración del contenedor cuando el objetivo es detectar errores de registro, dependencias ausentes o lifetimes incorrectos.

Separación entre pruebas que validan lógica aislada y pruebas que deben levantar el grafo real de dependencias.

Diagnóstico de errores de DI en suites TUnit, especialmente cuando aparecen solo en CI o en ejecución paralela.

Construcción de una configuración de DI de pruebas para una aplicación ASP.NET Core con servicios reales y dependencias sustituidas.

Diferenciación entre dummy, fake, stub, spy y mock para elegir el doble adecuado según comportamiento, interacción y coste de infraestructura.

Uso de frameworks de mocking como Moq, NSubstitute o FakeItEasy dentro de TUnit cuando se necesita aislar colaboraciones externas.

Creación de fakes manuales para dependencias con comportamiento estable, más legibles que un mock lleno de configuraciones complejas.

Diseño de tests centrados en resultado cuando la interacción interna no forma parte del contrato relevante.

Verificación de llamadas solo cuando la colaboración es comportamiento observable: publicación de evento, envío de email, auditoría o persistencia.

Simulación de errores externos, timeouts, respuestas inválidas, dependencias caídas y reintentos sin llamar servicios reales.

Evitación de mocks excesivos que duplican la implementación y hacen que cualquier refactorización rompa pruebas sin cambiar comportamiento.

Creación de spies simples para registrar llamadas y validar side effects sin acoplarse a una librería concreta.

Decisión entre mock, fake, TestServer, Testcontainers o implementación real según nivel de confianza buscado.

Elaboración de una guía de dobles de prueba para proyectos TUnit con ejemplos correctos y anti-patrones frecuentes.

Prueba de entidades, value objects, agregados, políticas y servicios de dominio sin depender de base de datos, frameworks web ni infraestructura externa.

Validación de invariantes ante escenarios válidos, inválidos, extremos, combinaciones raras y transiciones de estado sucesivas.

Creación de pruebas que documentan reglas de negocio con lenguaje claro, ejemplos representativos y nombres entendibles por el equipo.

Uso de builders para montar entidades y comandos con defaults seguros, haciendo visible solo lo relevante para cada escenario.

Verificación de value objects con igualdad, inmutabilidad, normalización, validación, operaciones propias y errores esperados.

Prueba de errores de negocio sin convertir todos los flujos esperados en excepciones genéricas difíciles de interpretar.

Validación de eventos de dominio generados por una operación relevante, sin acoplarse al mecanismo concreto de publicación.

Evitación de mocks en dominio puro cuando el comportamiento puede probarse directamente de forma más simple.

Identificación de lógica crítica escondida en controladores, repositorios o servicios procedurales que debería trasladarse a dominio.

Construcción de una suite TUnit de dominio con assertions expresivas, datos parametrizados y cobertura de casos límite.

Prueba de command handlers, query handlers, application services o casos de uso que coordinan dominio, permisos, persistencia e integraciones.

Aislamiento de puertos de salida mediante fakes o mocks para validar decisiones del caso de uso sin levantar infraestructura innecesaria.

Validación de flujos de éxito, errores de negocio, datos no encontrados, usuario sin permisos, dependencia fallida y conflicto de estado.

Comprobación de side effects relevantes: guardado de cambios, publicación de evento, auditoría, notificación, invalidación de cache o llamada externa.

Uso de resultados tipados para probar errores esperados sin depender de excepciones como mecanismo normal de control de flujo.

Prueba de transacciones, idempotencia, reintentos, duplicados y consistencia de efectos secundarios.

Diseño de escenarios con builders de comandos, usuarios, permisos, entidades existentes y respuestas de puertos.

Separación entre pruebas unitarias de caso de uso y pruebas de integración que validan EF Core, broker o APIs reales.

Revisión de application services demasiado grandes, con demasiadas dependencias o lógica de dominio mal ubicada.

Implementación de una suite de casos de uso con TUnit, datos parametrizados, fakes, assertions múltiples y diagnósticos claros.

Escritura de pruebas asíncronas correctas con TUnit, evitando bloqueos con `.Result`, `.Wait()` o esperas temporales innecesarias.

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

Comprobación de `CancellationToken` en consultas, llamadas HTTP, workers, handlers y operaciones largas.

Diseño de tests para timeouts y reintentos sin ralentizar la suite con delays reales excesivos.

Simulación de dependencias lentas, fallos transitorios, tareas canceladas y operaciones que completan fuera de plazo.

Validación de condiciones de carrera, ejecución concurrente, bloqueos, idempotencia y conflictos de actualización.

Uso de abstracciones de reloj, scheduler o temporizador para evitar pruebas no deterministas basadas en tiempo real.

Aplicación de assertions asíncronas de TUnit para comprobar excepciones, finalización y condiciones temporales.

Diagnóstico de tests que pasan falsamente porque no esperan la operación real o porque dejan tareas en segundo plano sin observar.

Construcción de una batería de pruebas sobre un servicio concurrente con cancelación, timeout, retry y resultados deterministas.

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

Elección entre fake repository, SQLite en memoria, base real en contenedor o entorno de integración según el riesgo que se quiere cubrir.

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

Prueba de mappings, owned types, constraints, relaciones, índices, claves compuestas y reglas de concurrencia.

Identificación de diferencias entre providers que pueden ocultar fallos reales, especialmente cuando una query funciona en memoria pero falla en SQL.

Aislamiento de datos por prueba mediante transacciones, schemas temporales, bases efímeras, prefijos únicos o limpieza controlada.

Uso de lifecycle hooks para crear y destruir datos de persistencia sin interferir con ejecución paralela.

Prueba de migraciones relevantes antes de release, comprobando pérdida de datos, defaults, cambios de columna, índices y rollback.

Medición del coste de pruebas de base de datos para decidir cuáles se ejecutan en PR y cuáles en pipelines profundos.

Construcción de una suite TUnit de persistencia con EF Core, datos aislados, asserts de query y diagnóstico claro de fallos.

Uso de `TUnit.AspNetCore` para pruebas de integración de aplicaciones ASP.NET Core con aislamiento por test e infraestructura compartida.

Creación de una factory basada en `TestWebApplicationFactory<TEntryPoint>` para mantener mejor correlación de trazas, logging por test y contexto TUnit.

Uso de `WebApplicationTest<TFactory, TEntryPoint>` como clase base para pruebas de API con factory compartida y configuración aislada por test.

Creación de clientes HTTP de prueba con `Factory.CreateClient()` para validar el pipeline real de ASP.NET Core.

Configuración de servicios, settings, autenticación, base de datos, logging y dependencias externas dentro del entorno de test.

Comprensión de la importancia del aislamiento porque la ejecución en paralelo puede hacer que recursos compartidos interfieran entre escenarios.

Uso de helpers como nombres o prefijos aislados por prueba para tablas, colas, claves de cache, buckets o recursos temporales.

Captura de logs y trazas asociadas a la prueba que dispara una petición, facilitando diagnóstico de fallos de integración.

Sustitución de servicios mediante extensiones de service collection, reemplazando clientes externos, repositorios, usuarios o proveedores de tiempo.

Construcción de una suite de integración ASP.NET Core con TUnit, HTTP realista, configuración aislada y datos independientes.

Validación de endpoints REST completos mediante llamadas HTTP reales sobre la aplicación bajo prueba, no solo invocando métodos internos.

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

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

Validación de Minimal APIs, controllers, endpoint filters, model binding, parámetros de ruta, query string y cuerpos JSON.

Comprobación de errores `400`, `401`, `403`, `404`, `409`, `422` y `500` controlado según política de la API.

Prueba de `ProblemDetails`, errores de validación, mensajes seguros, extensiones permitidas y trace IDs.

Diseño de helpers para enviar requests, deserializar responses y crear assertions HTTP sin repetir código en todos los tests.

Validación de paginación, filtros, ordenación, búsquedas, límites, campos opcionales y formatos de fecha.

Detección de cambios incompatibles en contratos HTTP antes de que afecten a frontends, integraciones o consumidores externos.

Construcción de una suite TUnit de API con escenarios de éxito, error, permisos, contrato y datos persistidos.

Configuración de usuarios de prueba con claims, roles, scopes, tenant, permisos y contexto de identidad sin depender de un proveedor externo real.

Validación de `401 Unauthorized` cuando falta autenticación y `403 Forbidden` cuando existe identidad pero no permiso suficiente.

Prueba de policies de ASP.NET Core sobre endpoints, recursos, operaciones, tenants y acciones sensibles.

Comprobación de autorización por recurso cuando el acceso depende de ownership, estado, departamento, organización o relación con la entidad.

Validación de que ocultar botones en UI no sustituye controles server-side en APIs, comandos, queries o handlers.

Prueba de cookies, tokens, headers, antiforgery, CORS, expiración de sesión y flujos protegidos cuando forman parte de la aplicación.

Comprobación de que respuestas y errores no exponen datos sensibles, tokens, secretos, claims internos o información de otros tenants.

Creación de matrices de prueba por rol, permiso, operación, endpoint y estado del recurso.

Diseño de pruebas de regresión para vulnerabilidades corregidas, asegurando que no reaparecen en futuras entregas.

Construcción de una suite AppSec básica con TUnit para endpoints críticos, permisos y protección de datos.

Prueba de middlewares personalizados con peticiones reales, validando orden, short-circuit, headers, logs y respuestas.

Validación del middleware global de excepciones para asegurar respuestas seguras, consistentes y sin detalles internos.

Comprobación de correlation IDs, request IDs, culture, tenant resolution, auditoría y contexto de usuario en el pipeline.

Prueba de endpoint filters, action filters, exception filters y authorization filters cuando modifican comportamiento propio de la aplicación.

Validación de rate limiting, CORS, compresión, cabeceras de seguridad y configuración de routing.

Diseño de casos con cuerpos malformados, content types incorrectos, métodos no permitidos y rutas no existentes.

Verificación de logs emitidos por middleware para confirmar que contienen contexto útil y no datos sensibles.

Control de errores técnicos para que no expongan stack traces, nombres de tablas, rutas internas o configuración.

Evitación de tests que prueban el framework en lugar de validar comportamiento propio o configuración crítica.

Implementación de pruebas TUnit sobre un pipeline ASP.NET Core con seguridad, errores, auditoría y correlación.

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

Sustitución de clientes externos por fakes, mocks, servidores HTTP de prueba o handlers controlados según nivel de confianza necesario.

Validación de serialización, deserialización, cabeceras, autenticación, timeouts, errores HTTP, throttling y payloads incompletos.

Simulación de respuestas `500`, `429`, timeout, token caducado, contrato incompatible, latencia alta y datos mal formados.

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

Control de logs durante errores externos para evitar exposición de tokens, payloads sensibles o datos personales.

Separación entre pruebas unitarias de mapeo, pruebas de contrato con stub y pruebas de integración contra sandbox autorizado.

Uso de TestContext y logging para diagnosticar qué llamada externa simulada produjo el fallo.

Creación de fixtures reutilizables para consumidores HTTP sin acoplar cada test al detalle de la infraestructura.

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

Prueba de `BackgroundService`, hosted services, jobs programados y workers sin depender de esperas reales ni bucles infinitos.

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

Simulación de colas, mensajes, timers, dependencias externas, errores transitorios y fallos permanentes.

Validación de procesamiento correcto, reintentos, dead letter handling, logging y métricas emitidas.

Comprobación de shutdown graceful mediante `CancellationToken`, asegurando que el servicio no deja operaciones críticas a medias.

Control de loops usando fuentes de mensajes, canales, schedulers o disparadores manuales que permitan pruebas deterministas.

Validación de idempotencia cuando el worker puede recibir el mismo mensaje más de una vez.

Diseño de tests para poison messages, payloads inválidos, dependencia caída, error de base de datos y recuperación posterior.

Separación entre pruebas unitarias del procesador y pruebas de integración con broker o cola realista.

Construcción de una suite TUnit de worker con cancelación, reintentos, errores, efectos observables y limpieza de recursos.

Prueba de productores de eventos validando tipo, payload, versión, metadata, correlation ID, causation ID y datos mínimos necesarios.

Validación de consumidores con eventos válidos, inválidos, duplicados, desordenados, tardíos y de versiones anteriores.

Uso de brokers en contenedor, fakes o Testcontainers según el nivel de realismo que la prueba necesita.

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

Validación de errores transitorios, errores permanentes, reintentos, dead letter queues y registro de fallos.

Prueba de patrones Outbox e Inbox cuando se requiere publicación fiable y deduplicación.

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

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

Medición de lag, mensajes pendientes, errores y tiempo de procesamiento cuando la integración lo justifica.

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

Uso de entornos reproducibles para ejecutar pruebas de integración con bases de datos, caches, brokers o servicios auxiliares.

Integración de TUnit con escenarios de Aspire cuando el equipo usa orquestación local y observabilidad de aplicaciones distribuidas.

Uso de Testcontainers para levantar PostgreSQL, SQL Server, Redis, RabbitMQ u otros recursos durante pruebas de integración.

Diseño de infraestructura compartida y datos aislados por prueba para combinar rendimiento con ejecución paralela segura.

Preparación de lifecycle hooks para arrancar, reutilizar y limpiar contenedores sin dejar recursos huérfanos.

Validación de connection strings, migraciones, seeds y readiness de servicios antes de ejecutar pruebas dependientes.

Control de tiempos de arranque, paralelización, puertos, redes, nombres únicos y limpieza de recursos.

Separación de pruebas que necesitan infraestructura real de pruebas unitarias que deben seguir siendo muy rápidas.

Diagnóstico de fallos que solo aparecen con infraestructura real: constraints, encoding, transacciones, colas, timeouts y permisos.

Construcción de un laboratorio TUnit con API, base de datos, cache, broker e integración reproducible en local y CI.

Integración de pruebas end-to-end cuando el riesgo funcional exige validar navegador, API, autenticación, UI y persistencia en conjunto.

Uso de Playwright junto a TUnit cuando el proyecto necesita probar flujos críticos completos con navegador real o headless.

Diseño de escenarios E2E limitados y de alto valor, evitando convertir toda la estrategia de calidad en pruebas lentas y frágiles.

Preparación de datos, usuarios, permisos y estado inicial para flujos de login, alta, edición, aprobación, búsqueda o exportación.

Validación de errores de usuario, mensajes, navegación, autorización visual y respuesta del backend ante operaciones completas.

Captura de screenshots, vídeos, trazas o logs de navegador cuando una prueba falla en local o CI.

Aislamiento de datos por ejecución para evitar que dos pruebas E2E se pisen entre sí.

Separación entre pruebas E2E de regresión crítica y pruebas de UI que deberían cubrirse con componentes o APIs.

Integración de E2E en pipelines nocturnos, pre-release o entornos efímeros según coste y criticidad.

Construcción de un flujo E2E mínimo con TUnit, navegador, API, base de datos, autenticación y diagnóstico de fallos.

Uso de filtros de TUnit para ejecutar subconjuntos de pruebas por namespace, clase, nombre, categoría o estructura de árbol.

Comprensión de la diferencia entre filtrado clásico de algunos runners y el filtrado propio disponible sobre Microsoft.Testing.Platform.

Definición de categorías para unitarias, integración, contrato, seguridad, E2E, lentas, flaky temporal o pruebas de infraestructura.

Aplicación de timeouts para evitar que una prueba bloqueada deje el pipeline colgado durante demasiado tiempo.

Uso de retries de forma controlada para escenarios transitorios conocidos, sin ocultar problemas reales de diseño o infraestructura.

Uso de repeat para detectar intermitencias, condiciones de carrera, problemas de paralelismo o fallos estadísticos.

Separación de filtros locales, filtros de pull request, filtros de release y filtros de diagnóstico profundo.

Configuración de ejecución selectiva en CI/CD para reducir tiempos sin dejar fuera escenarios críticos.

Documentación de categorías y filtros para que el equipo no ejecute accidentalmente una suite incompleta creyendo que está validando todo.

Construcción de comandos estándar de ejecución TUnit para desarrollo local, PR, nightly, release y análisis de flaky tests.

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

Publicación de resultados de pruebas, logs, reportes, cobertura, artefactos y diagnósticos para facilitar análisis de fallos.

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

Separación de pipelines rápidos de PR y pipelines profundos de release o nightly builds.

Uso de filtros y categorías para controlar qué pruebas se ejecutan en cada fase de entrega.

Gestión de variables, secretos, connection strings, servicios auxiliares y contenedores durante ejecución CI.

Diagnóstico de diferencias entre ejecución local y CI: rutas, permisos, cultura, zona horaria, paralelismo, recursos y versiones de SDK.

Optimización de tiempos mediante paralelización, cache de paquetes, infraestructura compartida y eliminación de tests redundantes.

Interpretación de cobertura como señal parcial, priorizando cobertura útil de reglas críticas, contratos, seguridad y regresiones.

Construcción de un pipeline de calidad con TUnit, cobertura, reports, filtros, infraestructura y bloqueo de cambios inseguros.

Comprensión del valor de la generación de código fuente y Microsoft.Testing.Platform para mejorar descubrimiento, ejecución y compatibilidad moderna.

Evaluación de compatibilidad AOT cuando el proyecto o sus pruebas deben ejecutarse en entornos optimizados, self-contained o con restricciones de reflexión.

Identificación de librerías, patrones o dependencias que pueden complicar AOT, trimming o ejecución optimizada.

Diseño de pruebas rápidas que no dependen de reflexión innecesaria, inicializaciones pesadas o discovery lento.

Medición de rendimiento de la suite por tiempo de descubrimiento, compilación, ejecución, paralelización y coste de infraestructura.

Separación entre optimizar la herramienta y optimizar el diseño de pruebas, porque una suite mal diseñada seguirá siendo lenta con cualquier framework.

Uso de paralelismo con aislamiento para mejorar throughput sin introducir flaky tests.

Revisión de tests lentos para decidir si deben optimizarse, moverse a otra fase o dividirse en pruebas más específicas.

Control de recursos compartidos que pueden convertirse en cuello de botella al ejecutar muchas pruebas en paralelo.

Creación de un plan de optimización de suite TUnit basado en métricas, no en percepciones del equipo.

Evaluación inicial de la suite existente: número de pruebas, tipos, fixtures, categorías, datos, paralelización, asserts, mocks y dependencias.

Mapeo de conceptos entre frameworks: atributos de test, setup, cleanup, theories, data sources, traits, categories, fixtures y assertions.

Migración incremental por proyecto, módulo o tipo de prueba, evitando convertir toda la suite de una vez sin validación.

Adaptación de assertions a la sintaxis de TUnit, prestando especial atención a su carácter asíncrono y al uso obligatorio de `await`.

Revisión de pruebas que dependían de estado compartido, orden de ejecución o comportamiento secuencial del framework anterior.

Sustitución de fixtures heredadas por hooks, data sources, factories o infraestructura más clara.

Ajuste de filtros en CI/CD, especialmente cuando el pipeline usaba filtros con semántica de otros runners.

Identificación de oportunidades de mejora durante la migración: eliminar tests inútiles, reducir mocks, aislar datos y estabilizar integración.

Ejecución paralela de suites antiguas y nuevas durante una fase de transición para asegurar equivalencia funcional.

Creación de un plan de migración documentado con riesgos, prioridades, responsables, checklist y criterios de finalización.

Diagnóstico de suites heredadas con tests lentos, opacos, dependientes del orden, con mocks excesivos o datos globales compartidos.

Identificación de pruebas que no aportan confianza porque solo validan implementación interna, getters, setters o detalles triviales.

Creación de pruebas de caracterización para capturar comportamiento actual antes de refactorizar código productivo o tests existentes.

Sustitución de setups gigantes por builders, data sources y escenarios más legibles.

Reducción de mocks profundos reemplazándolos por fakes simples, pruebas de integración o diseño más testable.

Aislamiento de recursos compartidos para permitir ejecución paralela sin fallos intermitentes.

Eliminación de sleeps, delays y dependencias temporales que provocan builds lentas o no deterministas.

Reescritura de assertions débiles para validar resultados, errores, contratos y efectos observables con más precisión.

Priorización de refactorización de tests por criticidad del módulo, frecuencia de fallos y coste de mantenimiento.

Creación de una estrategia de mejora continua de suite TUnit con deuda de testing, owners y revisión periódica.

Definición de criterios para decidir qué pruebas debe incluir un cambio según riesgo, capa afectada, contrato, seguridad y deuda existente.

Revisión de si las pruebas cubren happy path, errores, permisos, casos límite, datos inválidos y regresiones asociadas al cambio.

Evaluación de nombres, estructura Arrange-Act-Assert, datos, builders, assertions y diagnóstico de fallos.

Detección de tests acoplados a implementación que romperán ante refactorizaciones legítimas.

Revisión de uso correcto de TUnit: assertions esperadas con `await`, paralelización segura, datos aislados y hooks bien ubicados.

Identificación de pruebas de integración que deberían ser unitarias y pruebas unitarias que no dan confianza por exceso de mocking.

Comprobación de que los cambios de API incluyen pruebas HTTP, contrato, errores y autorización cuando corresponde.

Validación de que nuevos recursos externos tienen estrategia de sustitución o aislamiento en tests.

Creación de comentarios de revisión útiles que indiquen qué escenario falta, por qué importa y qué tipo de prueba conviene.

Implantación de una checklist de PR para testing TUnit en equipos .NET empresariales.

Definición de estándares internos sobre estructura de pruebas, nombres, data sources, assertions, hooks, categorías, CI/CD y diagnóstico.

Creación de una guía corporativa de TUnit para que distintos equipos escriban pruebas de forma consistente y mantenible.

Establecimiento de owners de la suite, evitando que las pruebas sean responsabilidad difusa de “QA” o “el pipeline”.

Diseño de métricas útiles: tiempo de ejecución, flaky tests, cobertura crítica, fallos por módulo, tests eliminados y defectos evitados.

Formación de desarrolladores para que escriban pruebas antes o junto al cambio, no como tarea final de baja calidad.

Revisión periódica de deuda de testing, eliminando pruebas redundantes, lentas, rotas u obsoletas.

Incorporación de testing en Definition of Done, pull requests, releases, refactorizaciones, migraciones y correcciones urgentes.

Creación de sesiones internas de mejora de suite para estabilizar integración, mejorar datos, reducir mocks y optimizar pipelines.

Alineación entre desarrollo, QA, arquitectura y DevOps sobre qué significa una suite fiable.

Construcción de una cultura donde TUnit sea una herramienta para aumentar confianza y velocidad, no una obligación burocrática.

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

Diseñar una estrategia de pruebas con unitarias, integración, API, contrato, seguridad, persistencia, workers y regresión.

Implementar pruebas de dominio con TUnit, builders, data-driven testing, assertions fluidas y escenarios de negocio críticos.

Crear pruebas de casos de uso con dobles de prueba, fakes, mocks, errores de negocio, permisos y efectos secundarios relevantes.

Configurar TUnit.AspNetCore, TestWebApplicationFactory y WebApplicationTest para validar APIs con cliente HTTP y contexto correlado.

Probar endpoints con respuestas HTTP, ProblemDetails, serialización JSON, autenticación, autorización, validación y datos aislados.

Integrar EF Core, base de datos de prueba, Testcontainers o infraestructura reproducible para validar persistencia y queries críticas.

Añadir pruebas de workers, eventos, integraciones externas, retries, timeouts, errores transitorios y deduplicación.

Incorporar ejecución CI/CD con filtros, categorías, cobertura útil, reporting, logs, quality gates y diagnóstico de fallos.

Presentar el proyecto con estructura de suite, decisiones técnicas, riesgos cubiertos, métricas, estándares y plan de mejora continua.