We have several test projects that directly access databases. These tests basically confirm our SQL queries written in C # code. Unfortunately, they are not separated at the moment and are in the same assemblies that also contain true, independent unit tests (I think that these database tests are considered an integration test, correct me if I am wrong).
We are currently using two settings files (sqlserver.testsettings and oracle.testsettings) to deploy another ConnectionStrings.config file before running the tests. Each of them has connection strings specific to their test databases, which must be created before running any tests. We do this because we want to test these database methods with both SqlServer and Oracle databases, as some of our clients use SqlServer and others use Oracle.
With that in mind, we have an app.config file in test projects that contains something in these lines:
<?xml version="1.0"?> <configuration> <connectionStrings configSource="ConnectionStrings.config"/> </configuration>
I would like to know if there is another way to do this without using the testsettings file, which in this case is already outdated in favor of the new format used by the "runsettings" files. However, I cannot find an equivalent function for creating custom files in the runsettings specifications and considered the possibility of creating several assembly configurations using XML transformations in ConnectionStrings.config or app.config files.
The problem with the XML transformations is that they are not currently supported for these types of projects, and it was very difficult for me to use SlowCheetah when moving to the build server and ultimately decided not to use it (I had the same configSource script in I tried to convert an external configuration file to one of our web application projects, so I combined the file with web.config and used the standard msdeploy conversion).
What would you recommend in this case? It should also be running on our build server. At the moment, we can specify the same tests that will be performed with both settings files.
Ideally, we would also like SqlServer tests to be the standard for all developers, and Oracle tests were selected only to run on our build server. This does not work right now, as each developer must specifically select the sqlserver.testsettings file before running the tests for the first time. With the idea of building a configuration, this can be achieved, so I am now inclined to this, but I would like to hear a potentially better approach to the problem.
I have a feeling that we are doing something very wrong in the whole process (and this includes the ideas presented in this post), and that there should be a much simpler and simpler way to do this.