2
votes

In our TFS 2013 project we have a set of simple MSBuild based integration tests alongside our unit tests which test stored procedures and other logic which need a database server to be present, for example

[TestMethod]
[TestCategory("Integration")]
public void SomeTest()
{
    InitialiseData();
    var results = RunStoredProcedure();
    AssertResultIsCorrect(result);
}

As you can see we have tagged these tests as "Integration" so that we can supply a test case filter that excludes these tests when we don't want to run them. These tests are all designed to run against an installed copy of our database (we have a process which deploys an up-to-date copy of our database to a SQL Server instance).

What we would like to do is create an integration test build definition in TFS which we can schedule to deploy our database and then run all of these tests against a specific SQL Server instance.

At the moment we use the standard TFS build process with two test sources - the first runs a "unit test" which installs the database, the second contains all of the actual integration tests. The problem we have is passing the connection string & database name into the unit tests from the build definition. Currently the connection string is in app.config files for each of the test projects, however this is less than ideal as it means that we are constantly getting failing test runs, either due to developers checking in the wrong connection string, or running tests locally against the build database at the same time that a build is running. This setup also limits us to running one build at a time.

Is there a way that we can specify the connection string and database name to use as part of the build workflow template instead?

1
can't you do this in your config file <connectionStrings configSource="cs.config"/> and produce a cs.config using WriteLinesToFile that you deploy in your test as a deploymentitem? I'm only thinking aloud...rene
@rene Something like that, I'm not sure how to pass those details from the build definition (i.e. workflow) to MSTest thoughJustin
I think his point is that you dont pass it to mstest, you just create the file in the temporary workspace on the buildserver using WriteLinesToFile, and the app.config of your test class references the file.Snorre

1 Answers

0
votes

With a combination of SlowCheetah for your config transformation and VS linked files, I think you can solve this (and based on the OP you probably already have :). Make a new solution configuration in your solution for the scenario you described. This solution will not be used on dev machines, only by TFS build definition (under Process, Items to build, Configurations to build).

enter image description here

The Configuration Manager for the solution would then use the solution configuration only for the test proj.

enter image description here

Add your SlowCheetah transform for your new solution configuration and put in your db conn string you need for TFS for that new transform.

Now in the tests project, copy over all the config files as linked files. This will allow the test executions to respect the test config file that SlowCheetah will transform. You may have to adjust your configuration reading in your test proj(s) to account for this.

This isolates the solution configuration to only the TFS server since only it will be building with your new solution configuration. Now TFS will have a config file that points to your specific TFS database connection that no other machines respect.