1

I have some integration tests that need to connect to a DB. In app.config I have a connection string which points to server '.' The tests run fine when I run them within VS on my workstation, as I have a SQL server instance also running locally.

We have a CI build & test set up to run on TFS, but in this environment the DB is not on the same machine, so the connectionstring in app.config is wrong and the tests fail to connect.

How can I configure a TFS CI build to update the app.config to point to a different DB? Or, is there a different way I should be solving this problem?

Simon Green
  • 1,131
  • 1
  • 10
  • 28

3 Answers3

0

You can use XML transformation to modify the app.config when you build the application through the TFS build (meaning that you'll have two solution configurations: one for local build with VS and the second for the TFS build) or you can use a pre-build script on build that'll modify the app.config connection string.

ds19
  • 3,176
  • 15
  • 33
0

You would be best moving integration tests out to a test environment. It's best if build are quick and don't need an instance of your application.

If you do a build and unit test you can have an automated release kick off in Release Management for Visual Studio which can be configured to also run integration and UI tests.

http://nakedalm.com/create-release-management-pipeline-professional-developers/

The release tool takes care of seeing connection strings and whatnot.

  • Hi, that's exactly when I am doing already. They already don't required an instance of the application. They run on the TFS build server as part of a CI configuration. If you could elaborate on your statement "The release tool takes care of seeing connection strings and whatnot." that might be helpful because I believe that covers my actual question - how to set a particular ConnectionString during a CI Test run. Or can it only update connection strings on deployment to a target environment (and not during a test run)? – Simon Green Jun 16 '15 at 14:48
  • The unit tests should run during the TFS build and shouldn't require an instance. The integration tests are requiring an instance and should run after the deployment of the application to a specific environment. The application deployment is handled by TFS Release Management which gives you the possibility to tokenize the app.configs for each environment. – ds19 Jun 16 '15 at 17:11
0

To solved this I choose the XML transformation route using the VS plug-in slowcheetah (idea taken here)

With this tool you create build configuration for each of your environments (ex: dev, QA, PP) and generate the XML transform of the app.config.

Replace the required section Example:

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <SqlUnitTesting xdt:Transform="Replace">
    <DataGeneration ClearDatabase="true" />
    <ExecutionContext Provider="System.Data.SqlClient" ConnectionString="Data Source=sqspsqlxx;Initial Catalog=IC_RMI_Result;Integrated Security=True;Pooling=False;MultipleActiveResultSets=False"
        CommandTimeout="30" />
    <PrivilegedContext Provider="System.Data.SqlClient" ConnectionString="Data Source=sqpsqlxx;Initial Catalog=IC_RMI_Result;Integrated Security=True;Pooling=False;MultipleActiveResultSets=False"
        CommandTimeout="30" />
  </SqlUnitTesting>

For TFS integration there is probably a way to use the out of box nuget restore but I simply added the package to source control.

At teamp build queue (or harcode in your build deinition) simply specify the build configuration you want to target (dev, qa, PP).

(note: my team build agent uses windows crendentials so I made sure the account has the required rights on the target DBs)

Community
  • 1
  • 1
Bhuard
  • 21
  • 2