Troubleshooting Data-Driven Unit Tests

You might encounter connection, authentication, deployment, or other problems when you run data-driven unit tests. Use the information in the following sections to solve those problems.

Test Cannot Connect to the Data Source

Make sure that the data source can be accessed by the user account used to run tests. To accomplish this, you must know which user account is being used to run tests. For example, when you run tests remotely, the tests run from the user account of the agent.

ASP.NET Issues

ASP.NET tests that run on an IIS Web server are run from the 'aspnet' account. Therefore, make sure that data source can be accessed by the ASP.NET user.

Also, if you use the 'Excel ODBC Dsn', you must create 'System Dsn'. System Dsn is available for all users. To create DSNs, use the ODBC Data Source Administrator. To do this, click Start, open Control Panel, open Administrative Tools, and then open Data Sources.

Deploying Data Source Files

If you use a data source file such as Microsoft Excel worksheet or a .CSV file, make sure that it is available when the test is run. One way to do this is to add the data source file as a deployment item by using the test run configuration dialog box, or as a per-test deployment item. Also, specify a relative path to the file. For more information about test run configurations, see Configuring Test Execution.

Authentication Issues

Use Windows Authentication whenever possible.

Connection Strings

Although the Data Connection dialog box works well for connecting to Microsoft SQL Server and Oracle, it is not convenient when you must establish a connection to file data sources. For those sources, you can specify a connection string and then select a data table name from a drop-down list box in the Properties window.

The following table contains examples of provider names and connection strings for most data providers.

Data Source

Provider name

Connection string

MS SQL Server (.NET provider)

System.Data.SqlClient

Data Source=SqlServerName;InitialCatalog=MyDatabaseName;Integrated Security=True;Connect Timeout=30;User Instance=True

MS SQL Express Server (.NET provider)

System.Data.SqlClient

Data Source=.\SQLEXPRESS;AttachDbFilename=C:\ \Test.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True

MS SQL Server (OLEDB, MDAC provider)

System.Data.OleDb

Provider=SQLOLEDB;Data Source= SqlServerName;Integrated Security=SSPI;Initial Catalog=MyDatabaseName

MS SQL Server (OLEDB, native client provider)

System.Data.OleDb

Provider=SQLNCLI;Data Source= MySqlServerComputerName;Integrated Security=SSPI;Initial Catalog= MyDatabaseName

MS SQL (ODBC)

System.Data.Odbc

Driver={SQL Server};Server=SqlServerName;Database=DatabaseName;Trusted_Connection=yes

Driver={SQL Server};Server=SqlServerName;Database=DatabaseName;Uid=UserName;Pwd=<password>

Oracle (.NET provider)

System.Data.OracleClient

Data Source=OracleServerName;Persist Security Info=True;User ID=scott;Password=<password>;Unicode=True

Oracle (OLEDB, Oracle provider)

System.Data.OleDb

Provider=OraOLEDB.Oracle;Data Source=OracleServerName;Persist Security Info=True;OSAuthent=1

Provider=OraOLEDB.Oracle;Data Source=OracleServerName;Persist Security Info=True;User ID=scott;Password=<password>

Oracle (OLEDB, Microsoft provider)

System.Data.OleDb

Provider=MSDAORA;Data Source= OracleServerName;Persist Security Info=True; User ID=scott;Password=<password>

Oracle (ODBC)

System.Data.Odbc

Driver={Microsoft ODBC for Oracle};Server=OracleServerName;Uid=scott;Pwd=<password>

Excel (OLEDB)

System.Data.OleDb

Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\ Test.xls;Persist Security Info=False;Extended Properties="Excel 8.0"

Excel (ODBC, MS Excel Driver)

System.Data.Odbc

Driver={Microsoft Excel Driver (*.xls)};DriverId=790;Dbq=C:\\Test.xls;DefaultDir=C:\

Tip   For Sheet1 table use Sheet1$ as data table name.

Excel (ODBC, Dsn)

System.Data.Odbc

Dsn=Excel Files;dbq=C:\Test.xls;defaultdir=C:\;driverid=790;maxbuffersize=2048;pagetimeout=5

Tip    When you run tests under ASP.NET, consider using System DSN instead of user DSN.

CSV/text file (OLEDB)

System.Data.OleDb

Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\;Extended Properties="text;HDR=Yes;FMT=Delimited”

Tip    For the test.csv file, use test#csv as the table name.

Note   HDR=Yes means that the first row contains column names, not actual data.

CSV/text file (ODBC)

System.Data.Obdc

Driver={Microsoft Text Driver (*.txt; *.csv)};Dbq=c:\;Extensions=asc,csv,tab,txt

ODBC through Dsn

System.Data.Obdc

Dsn=MyDsn;Uid=UserName;Pwd=<password>

FILEDSN=C:\MyDsn.dsn;Uid=UserName;Pwd=<password>

Specifying a Data Source Separately from Compiled Code

You can use the App.config file to specify a data source for your test. This lets you change data-source attributes, such as the server, table name, and so on, without recompiling the test assembly. When you run the test from the command line, make sure that the App.config file is in the same directory as the test assembly.

Example:

[TestMethod][DataSource("MyDataSource")]

[DeploymentItem("MyDataSource.csv")]public void MyTest() {}

Contents of the App.config file:

<configSections><section name="microsoft.visualstudio.qualitytools" type="Microsoft.VisualStudio.QualityTools.UnitTesting.Framework.TestConfigurationSection, Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/></configSections><microsoft.visualstudio.qualitytools><dataSources><add name="MyDataSource" connectionString="MyConnectionString" dataTableName="ChildSearchCriteria" dataAccessMethod="Sequential" /></dataSources></microsoft.visualstudio.qualitytools>

Note

The Run unit tests in application domain property determines whether each unit test assembly will run in a separate application domain. The default setting of the this property is True. If your unit tests do not require a separate application domain or app.config file to function correctly, your unit tests might run faster if you set the value of this property to False.

After Initializing the Database in TestInitialize, Your Changes Do not Appear

When the data-driven test runs, Unit Test Adapter connects to your data table and builds a list of data rows. Then for each row it executes the methods TestInitialize, TestMethod, and TestCleanup. If you change data rows in TestInitialize, the Unit Test Adapter will not see that change. Therefore, if you want to change your data table for a data driven test, do so in the ClassInitialize or AssemblyInitialize method.

The Unit Test Passes but Contains No Inner Results

This result means that your data table contains no rows.

Other Issues

If your issue is not listed here, you can try to search for answers on or post questions to the support forums and the individual forums for Visual Studio Team Edition for Developers and Visual Studio Team System Test Edition.

See Also

Tasks

How to: Configure a Data-Driven Unit Test

Concepts

Data-Driven Unit Tests