Test projects not reading app.config in TeamCity -> NUnit phase
Asked Answered
C

6

14

Well we are facing a strange problem with JetBrains TeamCity induced unit tests on our main project where tests from few library projects are failing regularly. Apparently, it's not reading the config file (coming from app.config and nicely stored in project -> bin -> debug -> projectName.dll.config).

Hints or tips on what could be the real issue would be highly appreciated.

Conduce answered 20/4, 2011 at 5:4 Comment(0)
G
22

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

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

**\*Tests.dll

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

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.

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.

Grivet answered 4/11, 2011 at 9:12 Comment(3)
That was really a good find so had to give it a +1 even though it helped me last yearConduce
As an addition to this, our project had multiple test dlls and one of them was referencing another. This caused the referenced dll to be run twice, and the copy that was in the other dll's folder didn't have the proper app.config entries. The proper fix was to remove any and all references from the other test project.Microbe
@DMactheDestroyer - you should put your comment as an answer. I didn't notice it at first and it ended up being the solution I needed.Refuse
M
16

In addition to Gaspar Nagy's accepted answer, check to see if your project has multiple test dlls and one of them is referencing another.

This causes the referenced dll to be run twice, and the copy that was in the other dll's folder to not have the proper app.config entries. The proper fix is to remove any and all references from the other test project.

Microbe answered 31/7, 2014 at 19:44 Comment(1)
This was my problem!!! Thank you very much! You answered my question.Kassandra
C
6

TeamCity (v6.5.4) has its own NUnit Test Runner and there seems to be an inconsistency between it and the NUnit GUI test runner (2.5.10). The NUnit GUI Test Runner follows the long standing convention of expecting the configuration file name to be of the format .config. You can see this in NUnit by looking at Project -> Edit...

TeamCity on the other hand is looking for an app.config.

Your options are to either:

  1. Set the NUnit GUI to point to app.config and include the resultant nunit project in your source control.
  2. Have both an app.config and a .config - syncing both manualy.
  3. Add a step to your build process to copy .config to app.config (or vice versa).
Copernicus answered 12/12, 2011 at 17:0 Comment(0)
D
0

I learned recently that app.config files are not read for a class library... Maybe this link could help :)

app.config for a class library

Dunsinane answered 20/4, 2011 at 5:44 Comment(2)
We are already using separate app.config and user.config(for individual developers) for our test projects(running since 2009). That discussion doesn't explain much on why it can't be used.Conduce
This is untrue. If your test project has its own App.Config file these settings will (and should) be accessible.Rumor
E
0

I had similar woes

This may help; additionally we had issues where this still would not work - we ended up copying the relevant config sections into the highest level config file. (i.e. if it was a web app copy it into the Web.Config) - fairly kludgy but we had wasted a few days on the issue

Endothecium answered 22/4, 2011 at 15:17 Comment(1)
Thanks for the reply Dean. Just a little bit confused though; our app.config is actually getting copied nicely in output dir but not being read at all. We are running on NUnit by the way. Let me know if I misunderstood your answer by the way. ThanksConduce
R
-4

If you need a config file for your "unit" tests then you are doing it wrong. Proper unit testing never needs configuration or access to the database, file system etc. You should change your testing strategy.

Good point to start is mark your tests that need configuration with the[Category("Integration")] annotation and set the Teamcity test runner to ignore this category. Then you should focus on refactoring these test.

Roque answered 21/4, 2011 at 7:9 Comment(3)
Thanks for the tips but my question is on a totally separate line..which asks why it's not reading the config file.Conduce
Is there a hard and fast rule that you can't use app.config for your test projects?(as for the assumption on integration tests, we have few integration tests under that project for which we use some keys from our config file). As a reference check the answer my Marc G. here for such a scenario, #931085Conduce
I would say no there is not such a rule for test projects. But I agree that you shouldn't need it for unit test in an ideal situation. However, test projects can be more than just unit tests, there can be integration or acceptance test and in those scenarios I think it is totally valid to use a configuration file.Isochor

© 2022 - 2024 — McMap. All rights reserved.