Problembehandlung für datengesteuerte Komponententests

Artikel
09/02/2008

Aktualisiert: November 2007

Beim Ausführen von datengesteuerten Komponententests können u. a. Probleme mit der Verbindung, Authentifizierung und Bereitstellung auftreten. In den folgenden Abschnitten finden Sie Informationen zum Lösen dieser Probleme.

Herstellen der Verbindung zur Datenquelle während des Tests nicht möglich

Stellen Sie sicher, dass mit dem Benutzerkonto, unter dem Tests ausgeführt werden, auf die Datenquelle zugegriffen werden kann. Hierfür müssen Sie das zum Ausführen von Tests verwendete Benutzerkonto kennen. Remotetests werden beispielsweise mit dem Benutzerkonto des Agents ausgeführt.

ASP.NET-Probleme

Auf einem IIS-Webserver ausgeführte ASP.NET-Tests werden mit dem ASPNET-Konto ausgeführt. Stellen Sie daher sicher, dass der ASP.NET-Benutzer auf die Datenquelle zugreifen kann.

Auch wenn der 'Excel ODBC Dsn' verwendet wird, müssen Sie einen 'System Dsn' erstellen. Der 'System Dsn' ist für alle Benutzer verfügbar. DSNs werden mit dem ODBC-Datenquellenadministrator erstellt. Klicken Sie hierzu auf Start, öffnen Sie Systemsteuerung und Verwaltung sowie anschließend Datenquellen.

Bereitstellen von Datenquelldateien

Wenn eine Datenquelldatei verwendet wird, z. B. ein Microsoft Excel-Arbeitsblatt oder eine CSV-Datei, stellen Sie sicher, dass diese beim Ausführen des Tests verfügbar ist. Ein Verfahren hierfür besteht darin, die Datenquelldatei als Bereitstellungselement im Dialogfeld Testlaufkonfiguration oder als Bereitstellungselement für einzelne Tests hinzuzufügen. Geben Sie auch einen relativen Pfad für die Datei an. Weitere Informationen zu Testlaufkonfigurationen finden Sie unter Konfigurieren der Testausführung.

Authentifizierungsprobleme

Verwenden Sie nach Möglichkeit immer die Windows-Authentifizierung.

Verbindungszeichenfolgen

Das Dialogfeld Datenverbindung ist zwar gut zum Herstellen von Verbindungen zu Microsoft SQL Server oder Oracle geeignet, jedoch nicht zum Herstellen von Verbindungen zu Dateidatenquellen. Für diese Quellen können Sie eine Verbindungszeichenfolge angeben und anschließend aus einer Dropdownliste im Dialogfeld Eigenschaften einen Datentabellennamen auswählen.

In der folgenden Tabelle finden Sie Beispiele für Anbieternamen und Verbindungszeichenfolgen der meisten Datenanbieter.

Datenquelle	Anbietername	Verbindungszeichenfolge
MS SQL Server (.NET-Anbieter)	System.Data.SqlClient	Data Source=SQL Server-Name;InitialCatalog=Name der Datenbank;Integrated Security=True;Connect Timeout=30;User Instance=True
MS SQL Express Server (.NET-Anbieter)	System.Data.SqlClient	Data Source=.\SQLEXPRESS;AttachDbFilename=C:\ \Test.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True
MS SQL Server (OLEDB- und MDAC-Anbieter)	System.Data.OleDb	Provider=SQLOLEDB;Data Source= SQL Server-Name;Integrated Security=SSPI;Initial Catalog=Name der Datenbank
MS SQL Server (OLEDB, Native Client-Anbieter)	System.Data.OleDb	Provider=SQLNCLI;Data Source= Name des SQL Server-Computers;Integrated Security=SSPI;Initial Catalog=Name der Datenbank
MS-SQL (ODBC)	System.Data.Odbc	Driver={SQL Server};Server=SQL Server-Name;Database=Datenbankname;Trusted_Connection=yes Driver={SQL Server};Server=SQL Server-Name;Database=Datenbankname;Uid=Benutzername;Pwd=<Kennwort>
Oracle (.NET-Anbieter)	System.Data.OracleClient	Data Source=Oracle Server-Name;Persist Security Info=True;User ID=arno;Password=<Kennwort>;Unicode=True
Oracle (OLEDB, Oracle-Anbieter)	System.Data.OleDb	Provider=OraOLEDB.Oracle;Data Source=Oracle Server-Name;Persist Security Info=True;OSAuthent=1 Provider=OraOLEDB.Oracle;Data Source=Oracle Server-Name;Persist Security Info=True;User ID=arno;Password=<Kennwort>
Oracle (OLEDB, Microsoft-Anbieter)	System.Data.OleDb	Provider=MSDAORA;Data Source= Oracle Server-Name;Persist Security Info=True; User ID=arno;Password=<Kennwort>
Oracle (ODBC)	System.Data.Odbc	Driver={Microsoft ODBC for Oracle};Server=Oracle Server-Name;Uid=arno;Pwd=<Kennwort>
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-Treiber)	System.Data.Odbc	Driver={Microsoft Excel Driver (.xls)};DriverId=790;Dbq=C:\\Test.xls;DefaultDir=C:\ Tipp* Verwenden Sie für die Tabelle Tabelle1 den Tabellennamen Tabelle1$.
Excel (ODBC, Dsn)	System.Data.Odbc	Dsn=Excel Files;dbq=C:\Test.xls;defaultdir=C:\;driverid=790;maxbuffersize=2048;pagetimeout=5 Tipp Verwenden Sie zum Ausführen von Tests in ASP.NET den System-DSN anstelle des Benutzer-DSNs.
CSV-/Textdatei (OLEDB)	System.Data.OleDb	Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\;Extended Properties="text;HDR=Yes;FMT=Delimited" Tipp Verwenden Sie für die Datei test.csv den Tabellennamen test#csv. Hinweis HDR=Yes bedeutet, dass in der ersten Zeile Spaltennamen und keine tatsächlichen Daten enthalten sind.
CSV-/Textdatei (ODBC)	System.Data.Obdc	Driver={Microsoft Text Driver (.txt; .csv)};Dbq=c:\;Extensions=asc,csv,tab,txt
ODBC über Dsn	System.Data.Obdc	Dsn=MeinDSN;Uid=Benutzername;Pwd=<Kennwort> FILEDSN=C:\MeinDSN.dsn;Uid=Benutzername;Pwd=<Kennwort>

Angeben einer vom kompilierten Code getrennten Datenquelle

In der Datei App.config können Sie eine Datenquelle für den Test angeben. Hierdurch können Sie die Datenquellenattribute ändern, z. B. Server, Tabellenname usw., ohne die Testassembly neu zu kompilieren. Wenn Sie den Test über die Befehlszeile ausführen, stellen Sie sicher, dass sich die Datei App.config im gleichen Verzeichnis wie die Testassembly befindet.

Beispiel:

[TestMethod][DataSource("MyDataSource")]

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

Inhalt der Datei App.config:

Hinweis:
Die Run unit tests in application domain-Eigenschaft legt fest, ob jede Komponententestassembly in einer separaten Anwendungsdomäne ausgeführt wird. Die Standardeinstellung dieser Eigenschaft ist True. Wenn für die Komponententests keine separate Anwendungsdomäne oder app.config-Datei für die ordnungsgemäße Funktionsweise benötigt wird, könnten die Komponententests durch Festlegen dieser Eigenschaft auf False eventuell schneller ausgeführt werden.

Die Run unit tests in application domain-Eigenschaft legt fest, ob jede Komponententestassembly in einer separaten Anwendungsdomäne ausgeführt wird. Die Standardeinstellung dieser Eigenschaft ist True. Wenn für die Komponententests keine separate Anwendungsdomäne oder app.config-Datei für die ordnungsgemäße Funktionsweise benötigt wird, könnten die Komponententests durch Festlegen dieser Eigenschaft auf False eventuell schneller ausgeführt werden.

Ihre Änderungen werden nach dem Initialisieren der Datenbank in TestInitialize nicht angezeigt

Beim Ausführen von datengesteuerten Testläufen wird vom Komponententestadapter eine Verbindung zur Datentabelle hergestellt und eine Liste der Datenzeilen erstellt. Für jede der Zeilen werden anschließend die Methoden TestInitialize, TestMethod und TestCleanup ausgeführt. Wenn Sie die Datenzeilen in TestInitialize ändern, wird diese Änderung nicht vom Komponententestadapter erkannt. Wenn Sie daher die Datentabelle für einen datengesteuerten Test ändern möchten, nehmen Sie diese Änderung in der ClassInitialize-Methode oder der AssemblyInitialize-Methode vor.

Der Komponententest ist erfolgreich, enthält jedoch keine inneren Ergebnisse

Dieses Ergebnis bedeutet, dass die Datentabelle keine Reihen enthält.

Andere Probleme

Bei Problemen, die hier nicht aufgeführt sind, können Sie in den Supportforen und den Einzelforen für Visual Studio Team Edition for Developers und Visual Studio Team System Test Edition nach Informationen suchen und Fragen stellen.

Freigeben über