Tengo un proyecto .NET que depende de una base de datos para la que estoy escribiendo pruebas de integración. Cuando ejecuto las pruebas, necesito que se ejecute un contenedor docker local. Se puede iniciar con el siguiente comando (desde la raíz de la solución):
docker compose up -d dbPor ahora, esto es lo suficientemente simple como para hacerlo manualmente pero, idealmente, levantar el contenedor se automatizaría cada vez que se ejecuten las pruebas. Con este fin, intenté agregar lo siguiente:
(solution root)/Directory.Build.props :
<SolutionRoot>$([System.IO.Path]::GetFullPath('$(MSBuildThisFileDirectory)'))</SolutionRoot> (solution root)/tests/IntegrationTests/IntegrationTests.csproj :
<Target Name="DbContainerUp" BeforeTargets="VSTest"> <Exec Command="cd $(SolutionRoot)" /> <Exec Command="docker compose up -d db" /> </Target> Esto funciona, pero solo cuando se ejecuta a través dotnet test . Si ejecuto las pruebas con Visual Studio Test Explorer o VSCode Test Runner, no se invoca el destino DbContainerUp . Supongo que esto se debe a que Test Explorer/Runner no invoca dotnet msbuild /t:VSTest (que es a lo que se traduce dotnet test ) pero no puedo encontrar ninguna documentación de qué objetivos (si los hay) VS y VSCode usan.
He investigado lo siguiente y aún no he encontrado un camino viable a seguir:
.runsettings no proporciona un punto de extensibilidad para ejecutar comandos.Por ahora, he resuelto esto agregando un AfterTargets="AfterBuild" al objetivo DbContainerUp de la siguiente manera:
<Target Name="DbContainerUp" BeforeTargets="VSTest" AfterTargets="AfterBuild"> <Exec Command="cd $(SolutionRoot)" /> <Exec Command="docker compose up -d db" /> </Target> Esto funciona porque VS (y VS Code) deben compilar el proyecto IntegrationTests como parte del descubrimiento de la prueba o antes de la ejecución de la prueba (según la implementación). Además, debido a que BeforeTargets y AfterTargets son cooperativos (cualquiera activará el destino personalizado), esto significa que dotnet test continúa comportándose como se esperaba.
Si bien esta no es una solución perfecta (cualquier compilación genérica de dotnet build también iniciará el contenedor), es aceptable para nuestras necesidades asegurarnos de que se inicie el contenedor.