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.

Gaspar Nagy
  • 4,422
  • 30
  • 42
user446923
  • 553
  • 1
  • 10
  • 20

6 Answers6

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.

Richard Ev
  • 52,939
  • 59
  • 191
  • 278
Gaspar Nagy
  • 4,422
  • 30
  • 42
  • That was really a good find so had to give it a +1 even though it helped me last year – user446923 Apr 16 '12 at 06:25
  • 3
    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. – DMac the Destroyer Jan 28 '14 at 16:48
  • @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. – Jason Jul 30 '14 at 22:36
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.

Community
  • 1
  • 1
DMac the Destroyer
  • 5,240
  • 6
  • 36
  • 56
  • This was my problem!!! Thank you very much! You answered my [question](https://stackoverflow.com/questions/50491319/nunit3-multiple-app-config-files-in-teamcity). – Vin Shahrdar May 24 '18 at 21:46
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).
Martin Clarke
  • 5,636
  • 7
  • 38
  • 58
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

Community
  • 1
  • 1
Bruno
  • 1,944
  • 13
  • 22
  • 1
    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. – user446923 Apr 20 '11 at 06:29
  • This is untrue. If your test project has its own App.Config file these settings will (and should) be accessible. – Doug Aug 21 '19 at 15:31
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

Community
  • 1
  • 1
Dean
  • 5,896
  • 12
  • 58
  • 95
  • 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. Thanks – user446923 Apr 27 '11 at 23:34
-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.

Joel Beckham
  • 18,254
  • 3
  • 35
  • 58
Aleš Roubíček
  • 5,198
  • 27
  • 29
  • 1
    Thanks for the tips but my question is on a totally separate line..which asks why it's not reading the config file. – user446923 Apr 27 '11 at 23:03
  • 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, http://stackoverflow.com/questions/930585/app-configs-and-mstest-project-null-reference-for-a-connection-string – user446923 Apr 27 '11 at 23:15
  • 5
    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. – Tomas Jansson May 12 '11 at 10:25