Visual Studio 单元测试 - 奇怪的行为
以前有人见过这种非常奇怪的行为吗？
- 我有一个包含 70 个单元测试的解决方案。它们全部通过我的开发机器。
- 每当我提交更改时，我们的持续集成过程就会启动，构建框最终将运行相同的 70 个单元测试。
- 构建箱中只有一项测试始终失败。
- 错误发生在仅从我们的单元测试数据库获取一条记录的一行中。 （我知道依靠数据进行单元测试很糟糕，但请不要关注这一点，因为它现在不相关）
- 最奇怪的事情是当我自己登录到构建框时，打开相同的 Visual Studio 解决方案并手动启动关闭单元测试。结果：全部通过！
有人遇到过这种奇怪的情况吗？我猜 Cruise Control.NET 和 MSTest 发生了一些奇怪的事情？
Has anyone seen this very strange behaviour before?
- I've got a solution whith 70 unit tests. All of them pass on my dev machine.
- Whenever I commit my changes, our continuous integration process kicks in and the build box will eventually run the same 70 unit tests.
- There is only ONE test in the build box that fails all the time.
- The error is in one line that only gets a record from our unit test db. (I know it sucks having unit test to rely on data but please don't focus on this as it's not relevant now)
- The most weird thing is when I logon myself to the build box, open up the same visual studio solution and manually kick off the unit tests. Result: ALL PASS!
Has anyone ever had this weird situation? I'm guessing there is some weird thing going on with Cruise Control.NET and MSTest?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您的单元测试运行程序肯定会生成一个良好的日志，显示准确的异常消息或错误吗？猜测它有点毫无意义，但“访问被拒绝”类型的错误将是一个明显的候选者。设置您使用的任何数据库引擎（您也忘记提及这一点）来为在构建 grunt 上运行测试的用户帐户提供对表的访问权限。
Surely your unit test runner produces a good log that shows the exact exception message or error? It's kinda pointless to guess at it but an "access denied" kind of error would be an obvious candidate. Setup whatever dbase engine you use (you forgot to mention that too) to give the user account that runs the tests on the build grunt access to the tables.
正如另一个答案中所说，当周围有详细的日志时，猜测它没有太大意义......
但是因为我多次遇到这种情况，所以无论如何，这里有一个猜测：
CI 服务器用来运行测试的帐户可能在数据库中没有适当的权限。这也可以解释为什么当您手动运行相同的测试（然后使用您的用户帐户）时会成功......
HTH！
托马斯
As said in another answer, it doesn't make too much sense to guess about it when there are detailed logs around...
But because I had this situation several times, here's a guess anyway:
The account, which is used by the CI server to run the tests, may not have appropriate permissions in the database. This would also explain, why the same test succeeds when you run it manually (then with your user account)...
HTH!
Thomas
感谢您的投入，但这根本与凭据无关。
我发现在该特定测试之前运行的其他测试使我的单元测试数据库处于不一致的状态，因此导致相关测试出现错误。
让单元测试依赖于数据并不是一个好的做法，所以除非你像我一样对它有极大的约束，否则这是向每个人的建议：不要依赖数据来进行单元测试！！！！确保您拥有所有好的东西，特别是一个好的 IOC/依赖注入器容器，这样您的类是松散耦合的，并且您可以模拟您可能想要轻松进行单元测试的任何接口！
thanks for your inputs but it wasn't anything related to credentials at all.
I've found out that other tests that were running before that particular one were leaving my unit test database in an inconsistent state, therefore causing errors to the test in question.
It's not a good practice to have your unit tests relying on data, so unless you are extremely bound to it like myself, this is what a recommend to everyone: DO NOT RELY ON DATA TO DO YOUR UNIT TESTING !!!! Make sure you have all the good stuff in place, specifically a good IOC/dependency injector container so your classes are loosely coupled and you can mock up any interface you may want to unit test easily!
如果您希望在构建服务器上运行系统测试，或者通常希望能够在任何计算机（包括您自己的计算机）上正确运行，那么您必须确保它们的状态是独立的。
在您的情况下，您应该让每个测试 init 准备它使用的数据库（通过复制基于文件的数据库或清空/填充基于服务的数据库）。每个测试还应该尝试撤消其更改（删除文件或空数据库），但不要假设其他测试已成功完成此操作。
If you have system tests that you want to run on your build server or in general, want to be able to run correctly on any machine, including your own, then you must make sure that their states are independent.
In your case, you should have each test init prepare the DB it uses (either by copying a file-based DB or by emptying/filling a service-based DB). Each test should also attempt to undo its changes (delete file or empty DB) but not assume that other tests have done so successfully.