使用Microsoft.NET.Build.Containers时，构建与测试的推荐实践咨询

一、运行测试的推荐方式 #

• 本地/CI前置测试：在触发容器镜像构建前，先执行dotnet test完成测试。这是最直接的方式，能快速反馈测试结果，避免测试失败时浪费镜像构建资源。示例流程：
  1. 恢复依赖：dotnet restore
  2. 运行测试：dotnet test --no-restore -c Release
  3. 测试通过后构建镜像：dotnet publish --os linux --arch x64 -c Release /t:PublishContainer
• CI流水线集成：在GitHub Actions、Azure Pipelines等CI工具中，将测试步骤设为镜像构建的前置依赖。比如在GitHub Actions中，配置步骤为：检出代码 → 恢复依赖 → 运行测试 → 构建并推送镜像，确保只有测试通过才会进入镜像构建阶段。

二、构建与测试一体化方案（避免重复构建） #

如果你习惯在同一构建流程中完成应用构建与测试，有两种适配Microsoft.NET.Build.Containers的方案：

方案1：自定义MSBuild目标，嵌入测试步骤 #

通过修改项目文件（.csproj 或 Directory.Build.props），添加自定义MSBuild目标，让测试自动在PublishContainer目标前执行，无需额外Dockerfile，全程复用.NET构建流程：

<Target Name="RunTestsBeforeContainerPublish" BeforeTargets="PublishContainer">
  <!-- 针对当前项目的测试项目，可根据解决方案结构调整路径 -->
  <Exec Command="dotnet test $(MSBuildProjectDirectory)/../MyApp.Tests --no-restore --no-build -c Release" />
</Target>

配置完成后，只需执行dotnet publish -c Release /t:PublishContainer，工具会先自动运行测试，测试通过才会继续生成容器镜像，完全避免重复构建应用。

方案2：结合自定义多阶段Dockerfile #

如果你想保留原有的多阶段构建+测试逻辑，可以通过工具的ContainerCustomDockerfile属性指定自定义Dockerfile，复用你熟悉的构建流程：

1. 在项目文件中添加配置：

<PropertyGroup>
  <ContainerCustomDockerfile>./Dockerfile</ContainerCustomDockerfile>
</PropertyGroup>

2. 编写包含测试步骤的多阶段Dockerfile：

# 构建与测试阶段
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["MyApp.csproj", "."]
RUN dotnet restore
COPY . .
RUN dotnet build -c Release --no-restore
# 在此阶段运行测试，复用构建输出，无需重新编译
RUN dotnet test -c Release --no-build --verbosity normal
# 发布应用
RUN dotnet publish -c Release -o /app/publish --no-build

# 最终运行镜像
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApp.dll"]

执行dotnet publish /t:PublishContainer时，工具会使用你定义的Dockerfile完成构建，在同一构建阶段完成编译、测试与发布，彻底避免重复构建。

内容的提问来源于stack exchange，提问作者Tomas Jansson