4

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.

julealgon
  • 7,072
  • 3
  • 32
  • 77
  • I realise this is a year old question, but what solution did you end up going with? I'm currently dealing with this same problem. – Kkov Aug 15 '14 at 05:07
  • The problem persists, actually. I still have no alternative, but we ended up letting another team handle Oracle support, and are now just running the SqlServer tests. There was a lot of conflict when we upgraded our TFS installation. Basically, TFS required a x64 windows installation, while our Oracle installation refused to work unless it was installed on a 32 bit OS. At the time, I remember reading that Oracle did not officially support 64 bits at all, and I'm not sure if the situation has changed. – julealgon Aug 15 '14 at 15:20
  • I must say I would absolutely not do this again on new projects though. I think the approach was completely wrong to begin with (the whole database testing on a build server). In more recent projects, we split the tests into true unit tests (that run on the build without external dependencies) and integration tests, that run on a environment with all prerequisites installed. Basically, in this case, I would then have a test machine in 32 bits mode with Oracle installed, and another test machine with 64 bit windows and SqlServer installed. Then, all integration tests would be run against both. – julealgon Aug 15 '14 at 15:22
  • For that multi-machine scenario to work seamlessly, we use Microsoft Test Center with Test Cases pointing to the integration tests, alongside the Lab Environment build workflow. This build runs after the normal build, deploys the outputs to the target machines, and then runs the tests against them via remote testing (Test Agent). I feel this is _much_ better than what we were going with. I'd highly recommend anyone in this situation to [evaluate how to use the Lab Management system](http://msdn.microsoft.com/en-us/library/hh191495.aspx), it really is a great tool – julealgon Aug 15 '14 at 15:26
  • Finally (and sorry for extending myself here), the reasonably new [Powershell Desired State Configuration mechanism](http://technet.microsoft.com/en-us/library/dn249912.aspx) can be used on the lab template to deploy your build outputs in a very elegant and simple way, so I also always recommend taking a look at that one. – julealgon Aug 15 '14 at 15:29

0 Answers0