【问题标题】:Visual Studio Unit Test - Weird behaviourVisual Studio 单元测试 - 奇怪的行为
【发布时间】:2011-07-31 20:50:27
【问题描述】:

以前有人见过这种非常奇怪的行为吗?

  1. 我有一个包含 70 个单元测试的解决方案。它们都在我的开发机器上传递。
  2. 每当我提交更改时,我们的持续集成流程就会启动,并且构建框最终将运行相同的 70 个单元测试。
  3. 构建框中只有一个测试始终失败。
  4. 错误出现在仅从我们的单元测试数据库中获取记录的一行中。 (我知道依靠数据进行单元测试很糟糕,但请不要关注这一点,因为它现在不相关)
  5. 最奇怪的是当我登录到构建框时,打开相同的 Visual Studio 解决方案并手动启动单元测试。结果:全部通过!

有没有人遇到过这种奇怪的情况?我猜 Cruise Control.NET 和 MSTest 发生了一些奇怪的事情?

【问题讨论】:

  • 是的,我猜是运行测试的用户没有有效的凭据。确保你的测试项目中有一个 app.config - 或者至少 link 它是你的真实配置。

标签: visual-studio unit-testing continuous-integration cruisecontrol.net mstest


【解决方案1】:

您的单元测试运行程序肯定会生成一个显示准确异常消息或错误的良好日志吗?猜测它有点毫无意义,但“访问被拒绝”类型的错误将是一个明显的候选者。设置您使用的任何 dbase 引擎(您也忘了提及),以便为在构建上运行测试的用户帐户提供对表的 grunt 访问权限。

【讨论】:

    【解决方案2】:

    正如另一个答案中所说,当周围有详细的日志时,猜测它并没有太大意义......

    但是因为我多次遇到这种情况,所以还是有一个猜测: CI 服务器用来运行测试的帐户在数据库中可能没有适当的权限。这也可以解释为什么当您手动运行相同的测试(然后使用您的用户帐户)时会成功...

    HTH! 托马斯

    【讨论】:

      【解决方案3】:

      感谢您的意见,但它根本与凭据无关。 我发现在该特定测试之前运行的其他测试使我的单元测试数据库处于不一致的状态,因此导致相关测试出错。 让你的单元测试依赖于数据不是一个好习惯,所以除非你像我一样非常依赖它,这是向所有人推荐的:不要依赖数据来做你的单元测试!!!!确保你有所有好的东西,特别是一个好的 IOC/依赖注入器容器,这样你的类是松散耦合的,你可以模拟任何你可能想要轻松进行单元测试的接口!

      【讨论】:

        【解决方案4】:

        如果您有系统测试要在构建服务器上运行,或者一般来说,希望能够在包括您自己在内的任何机器上正确运行,那么您必须确保它们的状态是独立的。

        在您的情况下,您应该让每个测试初始化​​准备它使用的数据库(通过复制基于文件的数据库或通过清空/填充基于服务的数据库)。每个测试还应尝试撤消其更改(删除文件或清空数据库),但不要假设其他测试已成功完成。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2015-02-03
          • 1970-01-01
          • 2010-09-18
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2012-03-20
          相关资源
          最近更新 更多