且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

测试项目未在 TeamCity 中读取 app.config ->NUnit阶段

更新时间:2023-02-11 09:47:45

我遇到了同样的问题,浪费了几个小时来弄清楚问题是什么.

I've got the same problem and wasted a couple of hours to figure out what the problem is.

在我们的例子中,NUnit 插件被配置为从以下位置运行测试:

In our case, the NUnit plugin was configured to run the tests from:

**\*Tests.dll

虽然这听起来没问题,但事实证明,此模式不仅与 bin\Debug 文件夹中的 MyTests.dll 匹配,而且与 obj\Debug\MyTests.dll 匹配.obj 文件夹用于内部编译,不包含配置文件.

Though this sounds to be OK, it has turned out that this pattern will not only match to the MyTests.dll in the bin\Debug folder but also to the obj\Debug\MyTests.dll. The obj folder is used internally for the compilation and does not contain the config file.

最后的解决办法是将插件配置改为

Finally the solution was to change the plugin configuration to

**\bin\Debug\*Tests.dll

实际上,我们在构建配置中使用了系统变量,因此我们没有硬编码调试".当工作区也用于调试/发布构建并且您没有指定完全清理时,使用 bin* 也可能很危险.

Actually we use a system variable for the build configuration so we did not have the "Debug" hard-coded. Using bin* might be also dangerous when the workspace is also used for Debug/Release builds and you don't have a full cleanup specified.

您可能想知道为什么我没有意识到测试计数不匹配(实际上是翻了一番,因为它们从 bin 运行一次,从 obj 运行一次),但这是典型的:虽然一切都是绿色的,但您不在乎伯爵.当我们根据配置引入第一个测试时,我们只有一个失败(因为来自 bin 的一个通过),所以重复并不突出.

You might wonder why I did not realize the test count mismatch (actually it was doubled, because they were running once from bin and once from obj), but this is typical: while everything is green, you don't care about the count. When we have introduced the first test depending on the config, we had only one failure (because the one from bin was passing), so the duplication was not outstanding.