locked
Per-user unit test database connection configurations? RRS feed

  • Question

  • Folks:

    I'm developing unit tests for stored procedures, and I am testing against a personal dev/test database.

    Unfortunately, because the database connection information resides in the app.config file, the connection settings for my personal dev/test database are being checked into revision control along with the rest of the unit test solution.

    I don't want other dev/qa (or the build server) to be running their unit tests against my dev/test database, and manually maintaining the app.config file before every commit is going to be tedious and easy to mess up.

    Is there a way to force VS2010 to prompt for the database connection settings every time the unit tests are run, or (better for the build server) a way to store the connection settings in a .user file that does not get checked into revision control?

    Thanks!

    Tuesday, February 1, 2011 6:12 PM

All replies

  • Hi,

    If your tests are run along with the build, then the best thing to do is that your post build activity should deploy the database on the build server along with any seed data. The app.config should point to server name (local). This way, the tests will always be run on the latest build on the build server.

    For anyone else who is running the tests, they will point to their local database and if they dont have any, the tests will fail and they will realize that they need to change the server name in the connection string. This way, no one else would be running their tests against your server.

    Thanks,

    Anuj

    Tuesday, February 1, 2011 6:21 PM
  • Thanks for the suggestion. Unfortunately the seed data needed by the unit tests is fairly complex and is rather a lot to load on every build - we'd probably set up a build test database with the seed data and a build step would be to load the current SPs on that database - and some of the unit tests are complex enough (yes, I know they should be kept simple, many if not most are quite simple) that running them against a database hosted on the dev's workstation (or, likely, on the build server) takes too long to be practical.

    And having another dev/qa change the connection string in app.config to their database so that they can run the unit tests, and then check that into revision control for whatever reason, leads to dueling connection strings in revision control - precisely the sort of thing the .user project files are intended to avoid.

    Tuesday, February 1, 2011 6:35 PM
  • Hi,

    If you will be using a build databse, you can specify its name in the config and check it in.

    For the other dev/qa, they can just replace the name to run tests on their individual servers and not check it in.

    If you want the other dev/qa to explicitly specify a server name before running the tests, you can write a utility which replaces the server name and call it in ClassInitialize.

    Thanks,

    Anuj

    Tuesday, February 1, 2011 6:54 PM
  • ...yeah, having a dedicated unit test/build database is an option.

    I didn't think of fixing the connect string in ClassInitialize, I'll have to look into that. Requiring a specific database name for per-dev unit testing isn't a painful restriction.

    You wouldn't happen to have a pointer to a code sample? :)

     

    Tuesday, February 1, 2011 6:57 PM