Curso de Testing en .NET con TUnit hasta 100% Bonificable a través de FUNDAE
Tu bonificación paso a paso
Forma a tu equipo sin costes mediante la bonificación estatal. Este programa de Testing en .NET con TUnitpara empresas es subvencionable hasta el 100%.
Potencia las habilidades de edición y automatización de tus profesionales.
Accede a una formación avanzada en Testing en .NET con TUnit práctica y orientada a resultados.
Prepara a tu equipo para los retos documentales del entorno laboral actual.
Gestionamos gratis tu bonificación de este curso corporativo de Testing en .NET con TUnit ante FUNDAE.
Impulsa calidad de código con Testing en .NET con TUnit A Medida, tutorizado para tu equipo, 100% bonificable por FUNDAE y mejora cobertura. Contáctanos.
Reduce pruebas flaky y fallos intermitentes La formación pone mucho foco en datos aislados, recursos únicos, limpieza correcta y eliminación de dependencias de orden. Esto mejora estabilidad en local y CI/CD, especialmente cuando la suite crece y se ejecuta en paralelo.
1
Personaliza el temario al 100% para tu equipo
Diseñamos una formación a medida utilizando los documentos y flujos de trabajo reales de tu empresa.
Nueva Plataforma de E-learningFormación en directo con plataforma de apoyo para reforzar el aprendizaje
Acceso a las grabaciones
Los alumnos podrán revisar las sesiones grabadas para repasar conceptos clave, recuperar explicaciones concretas o reforzar aquellos contenidos que necesiten después de la clase en directo.
Recursos formativos
Materiales, sesiones grabadas y documentación de apoyo quedan centralizados en la plataforma para que el equipo pueda consultarlos durante y después de la formación.
Confirmación de asistencia
La plataforma permite registrar y confirmar la asistencia de los participantes, facilitando el seguimiento de la formación y la gestión documental necesaria para la bonificación FUNDAE.
Programa formativo
Temario del curso
Encuentra todo el temario del curso aquí.
Temario
Definición de una estrategia de testing adaptada a aplicaciones .NET empresariales, separando pruebas unitarias, integración, API, contrato, seguridad, componente y regresión.
Identificación de qué debe probarse en dominio, aplicación, infraestructura, API, persistencia, autenticación, autorización, middlewares, workers e integraciones externas.
Análisis de riesgos habituales en suites .NET: lentitud, datos compartidos, pruebas flaky, mocks excesivos, asserts pobres, dependencias reales no controladas y baja confianza en CI.
Diseño de una pirámide de testing equilibrada, evitando que el equipo dependa de pruebas end-to-end lentas para validar reglas que deberían probarse antes.
Aplicación de TUnit como framework base para pruebas rápidas y paralelizables, aprovechando su enfoque moderno sin convertirlo en una moda técnica.
Relación entre arquitectura testable y coste de pruebas, mostrando por qué el código acoplado obliga a test suites frágiles y difíciles de mantener.
Definición de criterios para saber si una prueba aporta valor: detecta regresiones reales, es legible, determinista, rápida y fácil de diagnosticar.
Priorización de pruebas por riesgo: reglas críticas, permisos, contratos, persistencia, integraciones, errores de negocio y bugs recurrentes.
Diseño de una política de testing para pull requests, releases, hotfixes, migraciones, refactorizaciones y cambios de infraestructura.
Elaboración de una hoja de ruta para introducir TUnit en proyectos existentes sin paralizar al equipo ni reescribir toda la suite de golpe.
Definición de una estrategia de testing adaptada a aplicaciones .NET empresariales, separando pruebas unitarias, integración, API, contrato, seguridad, componente y regresión.
Identificación de qué debe probarse en dominio, aplicación, infraestructura, API, persistencia, autenticación, autorización, middlewares, workers e integraciones externas.
Análisis de riesgos habituales en suites .NET: lentitud, datos compartidos, pruebas flaky, mocks excesivos, asserts pobres, dependencias reales no controladas y baja confianza en CI.
Diseño de una pirámide de testing equilibrada, evitando que el equipo dependa de pruebas end-to-end lentas para validar reglas que deberían probarse antes.
Aplicación de TUnit como framework base para pruebas rápidas y paralelizables, aprovechando su enfoque moderno sin convertirlo en una moda técnica.
Relación entre arquitectura testable y coste de pruebas, mostrando por qué el código acoplado obliga a test suites frágiles y difíciles de mantener.
Definición de criterios para saber si una prueba aporta valor: detecta regresiones reales, es legible, determinista, rápida y fácil de diagnosticar.
Priorización de pruebas por riesgo: reglas críticas, permisos, contratos, persistencia, integraciones, errores de negocio y bugs recurrentes.
Diseño de una política de testing para pull requests, releases, hotfixes, migraciones, refactorizaciones y cambios de infraestructura.
Elaboración de una hoja de ruta para introducir TUnit en proyectos existentes sin paralizar al equipo ni reescribir toda la suite de golpe.
Tema 1: Estrategia profesional de testing en proyectos .NET con TUnit
Definición de una estrategia de testing adaptada a aplicaciones .NET empresariales, separando pruebas unitarias, integración, API, contrato, seguridad, componente y regresión.
Identificación de qué debe probarse en dominio, aplicación, infraestructura, API, persistencia, autenticación, autorización, middlewares, workers e integraciones externas.
Análisis de riesgos habituales en suites .NET: lentitud, datos compartidos, pruebas flaky, mocks excesivos, asserts pobres, dependencias reales no controladas y baja confianza en CI.
Diseño de una pirámide de testing equilibrada, evitando que el equipo dependa de pruebas end-to-end lentas para validar reglas que deberían probarse antes.
Aplicación de TUnit como framework base para pruebas rápidas y paralelizables, aprovechando su enfoque moderno sin convertirlo en una moda técnica.
Relación entre arquitectura testable y coste de pruebas, mostrando por qué el código acoplado obliga a test suites frágiles y difíciles de mantener.
Definición de criterios para saber si una prueba aporta valor: detecta regresiones reales, es legible, determinista, rápida y fácil de diagnosticar.
Priorización de pruebas por riesgo: reglas críticas, permisos, contratos, persistencia, integraciones, errores de negocio y bugs recurrentes.
Diseño de una política de testing para pull requests, releases, hotfixes, migraciones, refactorizaciones y cambios de infraestructura.
Elaboración de una hoja de ruta para introducir TUnit en proyectos existentes sin paralizar al equipo ni reescribir toda la suite de golpe.
Tema 2: Ecosistema TUnit y diferencias frente a frameworks tradicionales
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.
Tema 3: Instalación, configuración y estructura de proyectos TUnit
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.
Tema 4: Primeras pruebas con `[Test]`, Arrange-Act-Assert y nombres útiles
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.
Tema 5: Assertions fluidas y asíncronas en TUnit
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.
Tema 6: Datos parametrizados, arguments, matrix tests y custom data sources
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.
Tema 7: Lifecycle hooks, setup, cleanup y control de recursos
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.
Tema 8: Paralelización, aislamiento y diseño anti-flaky
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.
Tema 9: TestContext, output, logging y diagnóstico por prueba
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.
Tema 10: Dependency injection en pruebas TUnit
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.
Tema 11: Mocking, fakes, stubs y dobles de prueba en TUnit
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.
Tema 12: Testing de dominio, reglas de negocio y value objects
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.
Tema 13: Testing de servicios de aplicación, handlers y casos de uso
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.
Tema 14: Testing asíncrono, cancelación, concurrencia y timeouts
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.
Tema 15: Testing de persistencia con EF Core y bases de datos
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.
Tema 16: ASP.NET Core con TUnit.AspNetCore y TestWebApplicationFactory
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.
Tema 17: Testing de APIs REST, Minimal APIs y contratos HTTP
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.
Tema 18: Testing de autenticación, autorización y seguridad
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.
Tema 19: Testing de middleware, filtros y pipeline ASP.NET Core
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.
Tema 20: Testing de integraciones externas y clientes HTTP
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.
Tema 21: Testing de background services, workers y procesos asíncronos
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.
Tema 22: Testing de eventos, mensajería y consumidores
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.
Tema 23: Testing con Aspire, Testcontainers e infraestructura reproducible
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.
Tema 24: Playwright, pruebas end-to-end y validación de experiencia
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.
Tema 25: Filtros, categorías, timeouts, retries y repeats
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.
Tema 26: Reporting, CI/CD, cobertura y quality gates
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.
Tema 27: Native AOT, Microsoft.Testing.Platform y rendimiento de la suite
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.
Tema 28: Migración desde xUnit, NUnit o MSTest hacia TUnit
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.
Tema 29: Refactorización de suites legacy y reducción de pruebas frágiles
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.
Tema 30: Revisión de pull requests orientada a pruebas TUnit
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.
Tema 31: Gobernanza, estándares y cultura de testing con TUnit
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.
Tema 32: Proyecto final integrador: suite TUnit empresarial para una API .NET
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.
Perfiles profesionales
Pensado para quienes deben dominar Testing en .NET con TUnit en su día a día
Desarrolladores backend .NET
Este curso encaja con desarrolladores que trabajan con C#, ASP.NET Core, APIs, servicios, Entity Framework Core, workers o lógica de negocio y quieren profesionalizar sus pruebas con TUnit. Aprenderán a estructurar tests rápidos, expresivos y paralelizables, validando comportamiento real sin depender de configuraciones frágiles ni de datos compartidos entre pruebas.
Desarrolladores senior y tech leads
Los perfiles con responsabilidad técnica podrán utilizar el curso para definir estándares de testing con TUnit, revisar pull requests, reducir pruebas flaky, mejorar cobertura útil y establecer criterios claros sobre aislamiento, fixtures, assertions, datos de prueba y ejecución en CI/CD. El valor está en construir una suite sostenible y no solo en cambiar de framework.
Preguntas frecuentes
Resolvemos todas tus dudas sobre nuestra formación en Testing en .NET con TUnit
Explora las respuestas a las preguntas que guian a nuestra comunidad. Aqui encontraras claridad sobre como funciona todo, desde el acceso hasta los detalles de los cursos. Si buscas respuestas, este es el lugar para comenzar.
Sí. El curso parte de instalación, `[Test]`, assertions y estructura básica, pero avanza hacia uso profesional con data sources, hooks, paralelización, ASP.NET Core, CI/CD, infraestructura reproducible y migración desde otros frameworks.
TUnit está construido sobre Microsoft.Testing.Platform, usa generación de código fuente, soporta AOT y ofrece un modelo moderno de data-driven testing, hooks y assertions asíncronas. También se diferencia por su enfoque de ejecución paralela y extensibilidad.
Sí. TUnit usa assertions fluidas con `Assert.That(...)` y sus assertions deben esperarse con `await`. Esta es una diferencia importante respecto a otros frameworks y se trabaja desde el inicio del curso.
Sí. El curso incluye un bloque amplio de APIs con TUnit.AspNetCore, TestWebApplicationFactory, WebApplicationTest, HttpClient, autenticación, autorización, configuración aislada, logging correlado y validación de respuestas HTTP.
Sí. TUnit está orientado a ejecución paralela por defecto, por lo que el curso insiste en aislamiento de recursos, datos únicos, limpieza segura y uso controlado de mecanismos para limitar paralelismo cuando no exista alternativa razonable.
Sí. Se trabaja EF Core, SQLite, bases reales de prueba, Testcontainers, datos aislados, migraciones, queries, mappings y ejecución paralela sin interferencias.
Sí. TUnit no obliga a un framework de mocking concreto. El curso enseña a usar mocks, fakes, stubs y spies con criterio, pudiendo integrar Moq, NSubstitute, FakeItEasy u otras alternativas aprobadas por el equipo.
Sí. Se trabajan filtros, categorías, reporting, cobertura útil, quality gates, ejecución por fases, diagnóstico de fallos, pruebas lentas, pruebas flaky y publicación de resultados en pipelines corporativos.
Sí. El curso dedica un bloque específico a equivalencias, riesgos, assertions, fixtures, filtros, ejecución paralela y migración gradual desde xUnit, NUnit o MSTest.
Sí, como bloque avanzado y con criterio. Se trabaja Playwright con TUnit para flujos críticos, pero sin convertir toda la estrategia de calidad en E2E lentos y frágiles.
No. Es una formación corporativa práctica para equipos .NET. Está orientada a mejorar calidad, testing, CI/CD y mantenibilidad, no a preparar una certificación concreta.
Sí. Al tratarse de una formación corporativa en desarrollo .NET, testing, calidad, seguridad, CI/CD y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
Sí. El curso parte de instalación, `[Test]`, assertions y estructura básica, pero avanza hacia uso profesional con data sources, hooks, paralelización, ASP.NET Core, CI/CD, infraestructura reproducible y migración desde otros frameworks.
TUnit está construido sobre Microsoft.Testing.Platform, usa generación de código fuente, soporta AOT y ofrece un modelo moderno de data-driven testing, hooks y assertions asíncronas. También se diferencia por su enfoque de ejecución paralela y extensibilidad.
Sí. TUnit usa assertions fluidas con `Assert.That(...)` y sus assertions deben esperarse con `await`. Esta es una diferencia importante respecto a otros frameworks y se trabaja desde el inicio del curso.
Sí. El curso incluye un bloque amplio de APIs con TUnit.AspNetCore, TestWebApplicationFactory, WebApplicationTest, HttpClient, autenticación, autorización, configuración aislada, logging correlado y validación de respuestas HTTP.
Sí. TUnit está orientado a ejecución paralela por defecto, por lo que el curso insiste en aislamiento de recursos, datos únicos, limpieza segura y uso controlado de mecanismos para limitar paralelismo cuando no exista alternativa razonable.
Sí. Se trabaja EF Core, SQLite, bases reales de prueba, Testcontainers, datos aislados, migraciones, queries, mappings y ejecución paralela sin interferencias.
Sí. TUnit no obliga a un framework de mocking concreto. El curso enseña a usar mocks, fakes, stubs y spies con criterio, pudiendo integrar Moq, NSubstitute, FakeItEasy u otras alternativas aprobadas por el equipo.
Sí. Se trabajan filtros, categorías, reporting, cobertura útil, quality gates, ejecución por fases, diagnóstico de fallos, pruebas lentas, pruebas flaky y publicación de resultados en pipelines corporativos.
Sí. El curso dedica un bloque específico a equivalencias, riesgos, assertions, fixtures, filtros, ejecución paralela y migración gradual desde xUnit, NUnit o MSTest.
Sí, como bloque avanzado y con criterio. Se trabaja Playwright con TUnit para flujos críticos, pero sin convertir toda la estrategia de calidad en E2E lentos y frágiles.
No. Es una formación corporativa práctica para equipos .NET. Está orientada a mejorar calidad, testing, CI/CD y mantenibilidad, no a preparar una certificación concreta.
Sí. Al tratarse de una formación corporativa en desarrollo .NET, testing, calidad, seguridad, CI/CD y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
Diseñemos hoy el curso que tu empresa necesita
Cuéntanos tus objetivos de negocio y prepararemos una propuesta formativa bonificable totalmente ad hoc
Core Con TUnit.AspNetCore, TestWebApplicationFactory y pruebas HTTP realistas, el equipo puede validar routing, middleware, autenticación, autorización, serialización, errores y contratos de API con mucha más confianza.
2
Facilita migración desde frameworks anteriores El curso incluye criterios para migrar desde xUnit, NUnit o MSTest sin romper la suite ni perder cobertura. También aprovecha la migración para eliminar pruebas pobres, setups opacos y categorías mal diseñadas.
3
Refuerza CI/CD y quality gates La formación integra TUnit en pipelines con filtros, reporting, cobertura, diagnósticos, categorías y ejecución por fases. Esto convierte las pruebas en parte real de la entrega continua, no en una ejecución manual ocasional.
4
Aumenta mantenibilidad y legibilidad El uso de builders, data sources, assertions claras, hooks bien ubicados y convenciones de equipo reduce el coste de mantener la suite. Los tests dejan de ser ruido y pasan a documentar comportamiento real.
5
Conecta testing con arquitectura empresarial El programa cubre dominio, casos de uso, persistencia, APIs, eventos, workers, seguridad e infraestructura. Esto permite proteger sistemas complejos y no solo validar métodos aislados sin impacto real.
Después de la formación en directo, los alumnos podrán acceder a ejercicios prácticos para aplicar lo trabajado en clase y consolidar el aprendizaje con actividades guiadas.
Acceso a las grabaciones
Los alumnos podrán revisar las sesiones grabadas para repasar conceptos clave, recuperar explicaciones concretas o reforzar aquellos contenidos que necesiten después de la clase en directo.
Recursos formativos
Materiales, sesiones grabadas y documentación de apoyo quedan centralizados en la plataforma para que el equipo pueda consultarlos durante y después de la formación.
Confirmación de asistencia
La plataforma permite registrar y confirmar la asistencia de los participantes, facilitando el seguimiento de la formación y la gestión documental necesaria para la bonificación FUNDAE.
Ejercicios prácticos
Después de la formación en directo, los alumnos podrán acceder a ejercicios prácticos para aplicar lo trabajado en clase y consolidar el aprendizaje con actividades guiadas.
Practica y mejora con nuestra plataforma
Una plataforma practica, con IA integrada y pensada para que mejores desarrollando. Se adapta a tu ritmo, te corrige al instante y te muestra tu progreso real.
Correccion magica
Feedback inteligente
Aprende de cada acierto y fallo con explicaciones claras
Los equipos que crean controllers, Minimal APIs, middlewares, autenticación, autorización, filtros, validaciones y contratos HTTP podrán validar sus aplicaciones con TUnit y TUnit.AspNetCore. La formación trabaja pruebas de integración con TestWebApplicationFactory, WebApplicationTest, clientes HTTP, configuración de test, logging correlado y aislamiento por prueba.
QA técnico y perfiles de calidad
Los perfiles QA con base técnica podrán participar en la estrategia automatizada desde el repositorio, definiendo escenarios, datos, casos límite, errores, regresiones, pruebas de contrato y validaciones de seguridad. El curso les ayuda a conectar criterios funcionales con pruebas TUnit ejecutables en pipelines.
Equipos DevOps y plataforma
Los perfiles DevOps podrán integrar TUnit en pipelines, reporting, filtros, categorías, paralelización, AOT, contenedores, Aspire y entornos reproducibles. La formación les permite reducir builds inestables, diagnosticar fallos de pruebas y convertir la suite en un quality gate fiable.
Arquitectos de software
Los perfiles de arquitectura podrán usar TUnit para proteger boundaries, reglas de dominio, contratos, integraciones, eventos y decisiones técnicas críticas. El curso muestra cómo el diseño testable y la arquitectura desacoplada reducen el coste de probar y facilitan evolución segura del software.