SQL Server Unit Testing using Visual Studio 2010 and Visual Studio 2012 Side by Side

This post is important only if you need to open the same SQL Server unit test projects in both Visual Studio 2010 and Visual Studio 2012.

The SQL Server unit testing runtime components installed with SQL Server Data Tools (SSDT) are specific to Visual Studio 2010 and Visual Studio 2012.  When working with only one version of Visual Studio the appropriate version of the runtime components is installed and there is no issue, but some care is needed when Visual Studio 2010 and Visual Studio 2012 are used side-by-side on the same project.  Side-by-side use includes the following scenarios:

1. Using Visual Studio 2010 and Visual Studio 2012 on the same machine with SSDT installed in both. 
2. Developers on a team who are collaborating on the same SQL Server unit test project but using different versions of Visual Studio.
3. Building test projects on a build machine that is at a different version level than Visual Studio, for example, using Team Foundation Build 2010 to build projects that were worked on by Visual Studio 2012 or vice versa.

Side-by-side use affects the following:

• The app.config file in the test projects.
• The database unit testing runtime which is Visual Studio version specific.
• Custom test conditions, which extend the runtime above.

The impact on each is discussed further below.

Note:  If you modify or extend your test code other than by using custom test conditions, you will need to consider the side-by-side implications of your extension if the test project will be used in both versions of Visual Studio.

SQL Server Test Configuration

To accommodate working with both Visual Studio 2010 and Visual Studio 2012, the app.config file in a test project supports two parallel sections, one for each version.  The config sections are created and managed by the same SQL Server Test Configuration dialog in the two respective versions of Visual Studio (the dialog from Visual Studio 2010 is shown below).  Example configuration sections are included at the end of this post.

When working in Visual Studio 2010 you should create and edit the configuration using the dialog from that version.  If you open the same project in Visual Studio 2012 you should use the Visual Studio 2012 version of the dialog to ensure it is configured appropriately.  The dialog can be opened by right-clicking on the test project in Solution explorer or from the SQL menu when the project is selected.  The contents of the two sections are not synchronized automatically, so if you are using different Visual Studio versions you should ensure that both sets of configurations refer to the same project and database or your test results may differ when running the same tests from each version of Visual Studio.

SQL Server Database Unit Testing Runtimes

In addition to the MS Test infrastructure, which is installed with Visual Studio Professional and higher editions and with the Team Foundation Build service, the Server SQL Server database unit testing runtime must be installed on any computer on which SQL Server unit tests are to be developed, built or run.  This runtime is included in the SSDT Build Utilities which are installed with SSDT.  SSDT can be installed on Visual Studio 2010 and Visual 2012 side by side on the same computer allowing SQL Server unit tests to be developed, built and run from either version of Visual Studio.

If you need to build and run the tests on a computer that does not have Visual Studio and SSDT installed – for example, on a Team Foundation Build server – then you will need to install the SSDT Build Utilities manually.  SSDT Build Utilities are installed using the SsdtBuildUtilities.msi file, which is provided as part of a version-specific administrative installation of SSDT.  If you are using Team Foundation Build 2010 you should install the SSDT Build Utilities for Visual Studio 2010; if you are using Team Foundation Build 2012 you should install SSDT Build Utilities for Visual Studio 2012.  The SsdtBuildUtilties.msi should be installed from the location (/location) used for the administrative installation point.  Once installed, the app.config configuration section for the appropriate version Team Foundation Build version will be used, so ensure this has been created and is accurate.  For more information on setting up a build server see, How to: Run SQL Server Unit Tests from Team Foundation Build.  For more information on creating an administrative install point of SSDT, see, Install SQL Server Data Tools.

At build time, the $(VisualStudioVersion) MSBuild property is used to resolve the correct version of the SQL Server database unit testing runtime.  When working in Visual Studio 2010, this property is automatically set to 10.0, while in Visual Studio 2012, it is set to 11.0.  If you are building from the command line on a machine that has both VS 2010 and VS 2012, then you can explicitly set this property via the command line when you build the project.  For example, for a Visual Studio 2012 project, you can run ‘msbuild.exe /p: VisualStudioVersion=11.0 <projectfile>’.

Using Custom Test Conditions in Side-by-Side Scenarios

If you are using a custom test condition in your test project then you must ensure that you either include the test condition source code in your solution that is shared between Visual Studio versions and build it with your test, or install the custom test condition assembly that was compiled with the version of Visual Studio that is being used to develop and run the tests. 

If you plan to install the test condition assembly, then the following rules apply.

If you are running Visual Studio 2010 and Visual Studio 2012 side by side on a computer you will need to install both 2010 and 2012 versions of the test condition assembly.  The test conditions should be installed in parallel version-specific folders as follows:

Visual Studio 2010:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft\SQLDB\TestConditions

Visual Studio 2012: 

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\SQLDB\TestConditions

These locations are configurable by registry key if required.

Note:  References to installed custom test condition assemblies are added to your test project during the test development process when you first add a SQL Server unit test to the project, regardless of whether you use any custom conditions in your tests. 

If you have a build server that needs to build and run tests that use custom test conditions, then you must manually install the custom test condition assemblies on the server into the appropriate folder based on the server version.  You only need to install one version of the test condition assembly, regardless of the Visual Studio version in which the projects are developed. 

Again, at build time, Team Foundation Build will use the $(VisualStudioVersion) MSBuild property, if it has been defined, to determine the version-specific folder from which to load the test conditions.  If this property is not set on your build server then install only the Visual Studio 2010 versions of any custom test conditions being used in the Visual Studio 2010 folder described above.

Appendix

Example Side-by-Side app.config Configuration Sections

Visual Studio 2010:

<configuration>
  <configSections>
    <section name="SqlUnitTesting_VS2010" type="Microsoft.Data.Tools.Schema.Sql.UnitTesting.Configuration.SqlUnitTestingSection, Microsoft.Data.Tools.Schema.Sql.UnitTesting, Version=10.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  </configSections>
  <SqlUnitTesting_VS2010>
    <DatabaseDeployment DatabaseProjectFileName="..\..\..\AdventureWorks\AdventureWorks.sqlproj" Configuration="Debug" />
    <DataGeneration ClearDatabase="true" />
    <ExecutionContext Provider="System.Data.SqlClient" ConnectionString="Data Source=(LocalDB)\Projects;Initial Catalog=AdventureWorks;Integrated Security=True;Pooling=False" CommandTimeout="30" />
    <PrivilegedContext Provider="System.Data.SqlClient" ConnectionString="Data Source=(LocalDB)\Projects;Initial Catalog=AdventureWorks;Integrated Security=True;Pooling=False" CommandTimeout="30" />
  </SqlUnitTesting_VS2010>
</configuration>

 Visual Studio 2012:

 <configuration>
    <configSections>
        <section name="SqlUnitTesting_VS2012" type="Microsoft.Data.Tools.Schema.Sql.UnitTesting.Configuration.SqlUnitTestingSection, Microsoft.Data.Tools.Schema.Sql.UnitTesting, Version=11.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
    </configSections>
    <SqlUnitTesting_VS2012>
        <DatabaseDeployment DatabaseProjectFileName="..\..\..\AdventureWorks\AdventureWorks.sqlproj"
            Configuration="Debug" />
        <DataGeneration ClearDatabase="true" />
        <ExecutionContext Provider="System.Data.SqlClient" ConnectionString="Data Source=(LocalDB)\Projects;Initial Catalog=AdventureWorks;Integrated Security=True;Pooling=False" CommandTimeout="30" />
        <PrivilegedContext Provider="System.Data.SqlClient" ConnectionString="Data Source=(LocalDB)\Projects;Initial Catalog=AdventureWorks;Integrated Security=True;Pooling=False" CommandTimeout="30" />
    </SqlUnitTesting_VS2012>
</configuration>