我们正面临一个奇怪的问题,JetBrains TeamCity在我们的主项目中引发了单元测试,其中来自少数图书馆项目的测试经常失败。显然,它不是在阅读配置文件(来自app.config并且很好地存储在项目中 - > bin - > debug - > projectName.dll.config)。
关于可能是真正问题的提示或提示将受到高度赞赏。
答案 0 :(得分:21)
我遇到了同样的问题,浪费了几个小时来弄清问题是什么。
在我们的例子中,NUnit插件被配置为运行以下测试:
**\*Tests.dll
虽然听起来没问题,但事实证明这个模式不仅匹配bin \ Debug文件夹中的MyTests.dll,还匹配obj \ Debug \ MyTests.dll。 obj文件夹在内部用于编译,不包含配置文件。
最后解决方案是将插件配置更改为
**\bin\Debug\*Tests.dll
实际上我们使用系统变量进行构建配置,因此我们没有硬编码的“Debug”。当工作空间也用于调试/发布版本并且您没有指定完全清理时,使用bin *也可能是危险的。
你可能想知道为什么我没有意识到测试计数不匹配(实际上它是加倍的,因为它们是从bin运行一次而从obj运行一次),但这是典型的:虽然一切都是绿色的,你不关心伯爵。当我们根据配置引入第一个测试时,我们只有一个失败(因为bin中的那个失败了),所以复制并不是很好。
答案 1 :(得分:15)
除了Gaspar Nagy's accepted answer之外,还要检查您的项目是否有多个测试dll,其中一个是引用另一个。
这会导致引用的dll运行两次,而另一个dll的文件夹中的副本没有正确的app.config条目。正确的解决方法是从其他测试项目中删除任何和所有引用。
答案 2 :(得分:5)
TeamCity(v6.5.4)有自己的NUnit Test Runner,它与NUnit GUI测试运行器(2.5.10)之间似乎存在不一致。 NUnit GUI Test Runner遵循长期惯例,期望配置文件名的格式为.config。您可以通过查看Project - >在NUnit中看到这一点。编辑...
另一方面,TeamCity正在寻找app.config。
您可以选择:
答案 3 :(得分:1)
我有类似的困境
This可能会有所帮助;另外我们遇到的问题仍然无法解决 - 我们最终将相关的配置部分复制到最高级别的配置文件中。 (即如果它是一个网络应用程序将其复制到Web.Config中) - 相当愚蠢,但我们在这个问题上浪费了几天
答案 4 :(得分:0)
我最近了解到没有为类库读取app.config文件......也许这个链接可以帮助:)
答案 5 :(得分:-3)
如果您的“单元”测试需要配置文件,那么您做错了。正确的单元测试永远不需要配置或访问数据库,文件系统等。您应该更改测试策略。
开始的好处是标记需要使用[Category("Integration")]
注释进行配置的测试,并将Teamcity测试运行器设置为忽略此类别。然后你应该专注于重构这些测试。