时间戳

首页 > 解决方案 > Azure DevOps Pipeline：在本地通过的测试在管道上失败

unit-testing - Azure DevOps Pipeline：在本地通过的测试在管道上失败

问题描述

我们的团队正在尝试实施 Azure DevOps 管道，但我们遇到了一些问题。作为背景，我们在自托管的 Windows 服务器上运行测试。我们得到了所有工作的前端测试，但现在我们在让后端通过时遇到了问题。

虽然大多数测试都顺利通过，但我们有一些实例无法按预期工作。尽管它们应该能够并行运行，但我将其关闭以验证这不是问题所在。我也尝试过单独运行它们而没有任何明显的变化。

我们得到的错误只是简单的断言失败，如下面的错误，没有给我们太多信息。

 Error Message:
   Assert.AreEqual failed. Expected:<True>. Actual:<False>.

但是行号指向一个模拟设置，如下面的我不明白。

mockQueryHandler.Setup(x => x.Handle(It.IsAny<FindQuery>())).Returns(info);

目前给我们带来最多问题的测试类是测试我们的事件警报功能的测试类。似乎第一个测试将通过，但随后的测试失败。但是，我们有管道设置来重新运行任何失败的测试 3 次，直到它放弃。因此，在每次重新运行时，下一个测试都会通过。我唯一能想到的是，我们的自动模拟出于某种原因给我们带来了麻烦。我们根据AutoMock - How to unit test with Keyed Registrations设置它们 ？

我们将其模拟如下：

  var IAbstractEventFactoryMock = new Mock<IAbstractEventFactory>();
  using (var mock = AutoMock.GetLoose(builder => builder.RegisterInstance(IAbstractEventFactoryMock.Object).Keyed<IAbstractEventFactory>("EventLogFactory").Keyed<IAbstractEventFactory>("ArpEventLogFactory"))) {
...
}

下面是我们的 .runsettings 文件

<RunSettings>  
  <RunConfiguration>
    <ResultsDirectory>.\TestResults</ResultsDirectory>
  </RunConfiguration>

  <MSTest>
  </MSTest>
</RunSettings>

下面是我们用来运行测试的 YAML

steps:
- task: VSTest@2
  displayName: 'Run All Tests'
  inputs:
    testAssemblyVer2: |
     **\*ID_Test*.dll
     !**\*TestAdapter.dll
     !**\obj\**
    searchFolder: '$(System.DefaultWorkingDirectory)/ID_Test'
    runSettingsFile: 'ID_Test/.runsettings'
    runInParallel: false
    runTestsInIsolation: true
    codeCoverageEnabled: false
    testRunTitle: 'Unit Tests'
    platform: '$(BuildPlatform)'
    configuration: '$(BuildConfiguration)'
    diagnosticsEnabled: true
    rerunFailedTests: true
  continueOnError: true

同样，这些测试都在本地顺利通过，如果我在管道上运行足够多次，它们最终会通过。所以我认为问题不在于代码本身。似乎测试没有正确设置或清理。我主要是在寻找可以配置我的 yaml 或 runsettings 以尝试解决此问题的其他方式的任何想法。提前感谢您的任何帮助，如果我可以提供任何其他信息来帮助，请告诉我。

标签： unit-testingazure-devopsazure-devops-self-hosted-agentazure-devops-pipelines

解决方案

原来这只是我们测试的一个问题。在一些地方，我们会使用当前时间，这在本地很好，但是服务器的执行时间要长得多，这会产生一些错误。在具有与在本地运行测试相似的执行时间的代理上测试管道帮助我发现这不是管道的问题。

推荐阅读