首先,一些上下文:我有一个 Visual Studio 解决方案,其中包含几个生产类库和九个单元测试项目。所有项目都针对 .NET 5。我正在运行 .NET 5.0.401。所有单元测试项目都引用了coverlet.collector
. 我不使用旧coverlet.msbuild
包。根据我的阅读,使用XPlat Code Coverage
现在是 .NET Core 的惯用语。
我有一个用于 CI 构建的 Azure Pipelines 管道。作为该管道的一部分,我想运行所有单元测试,生成单元测试结果以上传到管道,并生成代码覆盖结果以上传到管道。我已经阅读了几篇似乎使这变得简单的博客文章和文档;但是,我发现它不过如此。
让我们从在我的本地工作站上运行一些命令开始。出于本练习的目的,我们假设我已经使用以下命令成功构建了解决方案:
dotnet build Solution.sln --configuration Debug
如果我运行这样的测试:
dotnet test Solution.sln --configuration Debug --no-build --no-restore --collect:"XPlat Code Coverage" --results-directory artifacts/test-results
然后我看到代码覆盖结果存储在以 GUID 命名的子目录中。为什么微软决定这样做我不知道,但那是我无法控制的。
(运行此命令并截屏后,我删除了该test-results
目录。)
请记住,我还想生成单元测试结果。为此,我将--logger trx
参数添加到同一命令行。这一次,创建了许多其他文件夹,其中包含看似重复的代码覆盖结果。此外,我得到了.trx
我正在寻找的文件。
.trx
您会注意到,除了我想要的九个文件之外,还有另外九个代码覆盖率报告。
在我的自托管管道构建代理上生成了类似的重复文件。在管道中,如果我尝试执行以下任务:
- task: 'PublishCodeCoverageResults@1'
displayName: 'Publish code coverage results'
inputs:
codeCoverageTool: 'Cobertura'
summaryFileLocation: 'artifacts/test-results/**/coverage.cobertura.xml'
我收到一个错误:
##[warning]Multiple file or directory matches were found. Using the first match: C:\agent\_work\38\s\artifacts\test-results\$redacted\In\redacted\coverage.cobertura.xml
##[error]No code coverage results were found to publish.
它在此处报告的目录不是我省略时生成的 GUID 目录--logger trx
之一,而是重复目录之一。
这个答案似乎表明我正在正确地做所有事情。我还对该答案发表了评论,希望得到一些帮助。
我有几个问题:
- 我
dotnet test
是否正确调用以便同时生成代码覆盖结果和.trx
文件? - 是否
dotnet test
支持这种情况? - Azure Pipelines 市场中的扩展功能现在
ReportGenerator
真的内置了dotnet
吗? - 哪些代码覆盖率结果是“真实”的?在发布代码覆盖率结果之前,是否需要将 GUID 文件夹复制到另一个位置?
- 我想指定一个 RunSettings 文件,以便执行诸如将具有某些属性的成员排除在代码覆盖引擎考虑之外的事情。RunSettings 是否与我的工作流程兼容?