这对我来说有点奇怪，我已经通过单元测试完成了几个微服务并且没有遇到过像这样的问题。问题是我的单元测试在本地传递，但某些在我们的构建服务器上失败。关于这一点的奇怪之处在于，如果我在构建脚本中挑出一个失败的测试，它将通过。如果我使用之前运行的测试运行它，我会得到失败结果。如果我远程进入测试服务器并访问测试结果文件并重新运行所有测试，它们都将通过。所以对我来说，这说明它与我的构建环境有关 - 可能是“跑步者”的背景。我在失败测试中遇到的具体错误是：
System.Data.Entity.Core.EntityException：底层提供程序在Open上失败。 ---＆GT; System.Data.SqlClient.SqlException：建立与SQL Server的连接时发生与网络相关或特定于实例的错误。服务器未找到或无法访问。验证实例名称是否正确，以及SQL Server是否配置为允许远程连接。
同样，测试已经运行并通过了在此失败测试之前访问数据库。此外，应该注意的是，这些测试使用存储过程来访问数据，并且还使用LINQ to SQL（.dbml）。我最初认为它与上下文没有被正确处理有关，但在IDisposable实现的几次迭代之后，并且在整个数据访问代码中使用语句，我认为我已经排除了这一点。我甚至扯掉了.dbml引用并新建了一个实体模型（.edmx），但在问题大大简化之后最终获得了相同的结果。我现在只用2个单元测试就可以重现这个问题，一个会通过，一个会失败。当单独运行时，它们都会通过，当在本地或在构建服务器上手动运行时，两者都将通过。
我们将开发环境设置为远程服务器。所有开发者都使用VS 2013 Ultimate。所有开发人员都使用localdb的共享实例。这似乎工作正常，我能够开发和测试这种环境。我所有的测试都在这里通过了解决方案。然后我将代码上游推送到构建服务器。
这是安装了GitLabs的Windows 2012服务器，我们的dev分支的每次提交都通过.gitlab-ci.yml构建脚本运行构建。在大多数情况下，这只是简单的msbuild - ＆gt; mstest打电话，没什么太花哨的。此服务器还有自己的localdb共享实例，该实例使用Dev环境中的匹配模式运行。其他几个存储库使用此设置传递构建/单元测试。用于访问数据的连接字符串都使用集成安全性，gitlab runner服务帐户具有localdb的完全权限。我唯一可以确定的有关解决方案的显着不同的是大量使用sprocs，但是就像我说的一些单元测试确实通过了它们全部使用sprocs。就像我也提到的那样，在构建失败之后，如果我手动进入并访问测试结果文件并手动调用构建服务器上的测试，它们突然全部通过。
所以我不确定这里发生了什么，以前有没有人经历过这种行为？如果是这样，你是如何解决的？我想让这些测试通过，这样我的构建就可以通过并继续前进。
答案 0 :(得分：0)
好的，我已经通过了单元测试，但是我最终做了一些奇怪的事情让他们通过了，我不太确定为什么会这样。即使跑者帐户已经完全＆＃34;服务器角色＆＃34; localdb实例上的privs（检查了所有方框）我决定抛出一个冰雹结婚并经历了＃34;映射＆＃34;用户到相关数据库，将其默认架构设置为dbo并为其提供完全权限（所有框都已选中）。在此操作之后...测试通过。所以我显然没有理解有关在localdb中传播权限的方式，我假设一个类似神的服务器角色会暗示个人dbs的完全权限，但我猜不是吗？我不是DBA，我实际上会和我们的DBA聊天，看看他的想法。也许这与sproc执行有关？也许这需要特殊的权利？我知道在传递中我必须创建特殊角色来执行sprocs，所以它们有点挑剔。无论如何，单元测试通过，所以我现在开心了！