I have begun a new winforms project where I’m using a three-tiered architecture including an Object Relational Mapper (NHibernate), an automated testing suite (NUnit) and a light, easy-to-distribute database (SQLite).

This has not been without problems, but the issue I’m going to post about here is rather small, although it took me a while to figure out.

The thing is that NHibernate uses the app.config file for the database connection settings. My solution is divided into 4 projects, one of them being the unit-testing project, and when I executed my solution normally and ran a small non-nunit test I had no problem connecting to the database through NHibernate, but when I ran the tests through the NUnit-gui program, the app.config was not loaded and therefore the database connection test failed.

Normally this should be solved by placing the config file in the same directory as the dll that is being tested and calling it the same, i.e. “Tester.dll.config”, but in my case this just didn’t do it. Until I found some advice telling me to name the config file the same as the nunit-project and placing it in that same directory. So I had a Tester.unit file and a Tester.config file. That did it, but I was wondering why so many people wrote about the other way of doing it. And finally I found out why:
The problem is that there are two ways of loading a dll for testing in the NUnit-gui program. One is to create a new project and then choose the dll’s that should be tested. That was what I did. But the other, and simpler, is just to load the dll directly without creating a project in NUnit-gui first. In that last case you have to name the config file the same as the dll as I wrote above and place it in the same directory.

Actually it was a pretty simple solution, but I find it quite non-intuitive to have two ways of doing the same thing, but with two different default sideeffects of working with the config file.