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

问题描述

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

虽然大多数测试通过都很好，但在少数情况下，它无法按预期工作。尽管它们应该能够并行运行，但是我关闭了该功能以验证这不是问题。我还尝试了在没有任何明显变化的情况下独立运行它们。

我们得到的错误只是简单的断言故障，例如下面的那种，不会给我们太多信息。

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

但是行号指向的是一种模拟设置，就像我不明白的那样。

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

目前，给我们带来最多问题的测试类是测试事件警报功能的类。似乎第一个测试将通过，但随后的测试将失败。但是，我们拥有管道设置，可以将任何失败的测试重新运行三遍，直到放弃为止。因此，每次重新运行都会通过下一个测试。我唯一能想到的就是我们的自动模拟由于某种原因给我们带来麻烦。我们按照 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或运行设置以尝试解决此问题。预先感谢您的帮助，如果可以提供其他任何信息，请让我知道。

解决方法

您可以使用Visual Studio Test Platform Installer任务来运行测试，而无需完全安装Visual Studio。您可以尝试在VSTest任务之前添加此任务，然后选择适当的版本。然后在VSTest任务中，在Installed by Tools Installer下选择Test platform version：

,

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