https://patterns.exeal.com/tags/testcontainers/Recent content in Testcontainers on Patrones — ExealHugoes-ESThu, 24 Sep 2026 00:00:00 +0000https://patterns.exeal.com/patterns/tests-aceptacion-sobre-imagen-docker/Thu, 24 Sep 2026 00:00:00 +0000https://patterns.exeal.com/patterns/tests-aceptacion-sobre-imagen-docker/<h2 id="problema">Problema</h2> <p>Un backend .NET no se despliega como código fuente: se despliega como imagen Docker. Entre el código que pasa los tests unitarios y la imagen que corre en producción hay una capa entera que ningún test contra el código fuente toca — el <code>Dockerfile</code>, las variables de entorno que el contenedor espera recibir, si el puerto publicado es el correcto, si las migraciones corren al arrancar, si el healthcheck responde. Un <code>WebApplicationFactory</code> o un test de integración que arranca la app in-process compila contra las mismas clases que ya se probaron, así que no puede detectar ninguno de esos fallos — están todos fuera del código, en el empaquetado.</p>https://patterns.exeal.com/patterns/tests-de-persistencia-del-repositorio-real/Thu, 24 Sep 2026 00:00:00 +0000https://patterns.exeal.com/patterns/tests-de-persistencia-del-repositorio-real/<h2 id="problema">Problema</h2> <p>Con el patrón Repositorio, la lógica de negocio se testea contra una implementación fake en memoria del repositorio: rápida, sin dependencias externas, perfecta para cubrir reglas de negocio con muchos casos. El problema es que esos tests solo prueban la lógica de negocio — nunca ejercitan la implementación real del repositorio, la que de verdad habla con la base de datos en producción.</p> <p>Eso deja un hueco concreto: una query LINQ que EF Core no puede traducir a SQL y falla en tiempo de ejecución, un <code>GroupBy</code>/<code>Join</code>/<code>Distinct</code> que en memoria cuenta bien porque ejecuta el mismo predicado C# pero en SQL agrupa distinto, una constraint única que en producción vive en el esquema de la base de datos pero que el fake in-memory no reproduce porque no impone ninguna unicidad, una condición de carrera que solo se resuelve con un <code>INSERT ... ON CONFLICT</code> real. Nada de esto puede fallar en un test contra el fake, porque el fake y la implementación real solo comparten la interfaz — su comportamiento interno es completamente distinto. El fake existe justamente para no pagar el coste de hablar con una base de datos real en cada test de negocio, así que por construcción no puede detectar estos fallos.</p>