Troubleshooting Data-Driven Unit Tests

Collapse All

This page is specific to

Microsoft Visual Studio 2008/.NET Framework 3.5

Other versions are also available for the following:

Microsoft Visual Studio 2005/.NET Framework 2.0

Visual Studio Team System

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:

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.

Tasks

How to: Configure a Data-Driven Unit Test

Concepts

Data-Driven Unit Tests