We have multiple test projects that access databases directly. Those tests basically validate our sql queries written in C# code. Unfortunately, they are not separated at the moment and are in the same assemblies that also house true, non-dependent Unit tests (I think those database tests are considered Integration test, correct me if I'm wrong).
Currently, we use 2 testsettings files (sqlserver.testsettings and oracle.testsettings) to deploy a different 'ConnectionStrings.config' file before running the tests. Each of them have connection strings specific to their test databases, that should be created before any tests are run. We do this because we want to test these database methods with both SqlServer and Oracle databases, since some of our clients use SqlServer while others use Oracle.
With this in mind, we have an 'app.config' file on the test projects that contains something along these lines:
<?xml version="1.0"?>
<configuration>
<connectionStrings configSource="ConnectionStrings.config"/>
</configuration>
I would like to know if there would be another way to do this without using the testsettings file, which is in this case already deprecated in favor of the new format used by 'runsettings' files. I can't find the equivalent custom-file-deployment feature on runsettings specifications though, and considered creating multiple build configurations using XML transformations over the ConnectionStrings.config or app.config files.
The problem with XML transforms is that it is currently not supported for these types of projects, and I had a very hard time with SlowCheetah when going to the build server, and ultimately decided against using it (I had this same configSource scenario on one of our Web Application projects and tried transforming the external config file. I ended up merging the file with the web.config and using the standard msdeploy transformation).
What would you recommend in this case? This must also be runnable on our build server. At the moment, we can specify the same tests to be run with both testsettings files there.
Ideally we would also like that SqlServer tests be the standard for all developers, and Oracle tests would only be selected to run on our build server. This does not work right now, since every developer needs to specifically select the sqlserver.testsettings file prior to running the tests the first time. With the build configuration idea this could be achieved, so I'm leaning towards that at the moment, but I would like to hear a potentially better approach to the problem.
I have a feeling we are doing something very wrong in this whole process (and this includes the ideas presented in this post) and that there should be a much easier and straightforward way of doing it.