Übersicht über Komponententests

Aktualisiert: November 2007

Komponententests sind programmgesteuerte Tests, die in Visual C#, Visual Basic oder Visual C++ geschrieben werden. Tests in Visual C++ müssen mit /clr:safe kompiliert werden.

Hinweis:
Weitere Informationen über die Verwendung von Komponententests mit C++-Produktionscode und von in C++ geschriebenen Komponententests finden Sie unter Komponententests und C++.

Mithilfe von Komponententests wird weiterer Quellcode ausgeführt, indem die Methoden einer Klasse direkt aufgerufen und die geeigneten Parameter übergeben werden. Wenn Sie zusätzlich Assert-Anweisungen verwenden, können die erzeugten Werte anhand der erwarteten Werte getestet werden. Komponententestmethoden befinden sich in Testklassen, die in Quellcodedateien gespeichert werden.

Komponententests können mit einem Feature zur Codegenerierung erstellt werden, das den anfänglichen Quellcode für den Test erstellt, oder Sie können den Test vollständig von Hand schreiben. In beiden Fällen werden die Testklasse und sämtliche Testmethoden anhand programmgesteuerter Attribute identifiziert.

Jede Testklasse wird mit dem [TestClass()]-Attribut gekennzeichnet. Jeder Komponententest ist eine Testmethode, die mit dem [TestMethod()]-Attribut gekennzeichnet wird. Diese Attribute werden beim Generieren von Komponententests automatisch zugewiesen. Wenn Sie Code für Komponententests von Hand schreiben, müssen Sie die Klassen- und Methodenattribute selbst hinzufügen. Weitere Informationen finden Sie unter Struktur von Komponententests.

Generieren von Komponententests

Sie können Komponententests in einem Dialogfeld generieren, zu dem Sie über die Fenster des Tools Visual Studio gelangen. Jeder Komponententest wird als Methode in C#, Visual Basic oder Visual C++ erstellt. Der Code und die Attribute des Tests befinden sich in einer Quelldatei in einem für dieselbe Sprache erstellten Testprojekt. Der neue Test zielt auf einen bestimmten Code ab, den Sie testen möchten. Sie können einen einzelnen Komponententest für eine bestimmte Methode generieren, oder Sie können mehrere Tests für ausgewählte Methoden oder für alle Methoden in einer Klasse oder einem Namespace erzeugen.

Sie können Komponententests vom Quellcode im aktuellen Projekt generieren. Sie können Komponententests auch von einer Assembly im Dateisystem generieren. Dies ist hilfreich, wenn kein Quellcode verfügbar ist.

Der Code eines neu generierten Tests wird kompiliert, doch um sinnvolle Testergebnisse zu liefern, muss er noch bearbeitet werden. Sie können den Test beispielsweise bearbeiten, um Variablenzuweisungen vorzunehmen und Assert-Anweisungen anzupassen. Generierte Komponententests enthalten TODO-Anweisungen, die anzeigen, welche Codezeilen bearbeitet werden müssen.

Hinweis:

Testtools in Team System verwendet beim Generieren von Komponententests bestimmte Namenskonventionen. Beispielweise wird einer Testdatei ein Name zugewiesen, der sich aus dem Wort "Test" und dem Namen der Datei zusammensetzt, die den zu testenden Code enthält (z. B. "Class1Test.cs"). Die Namen der Testklassen und Testmethoden werden ebenfalls nach Standardvorgaben generiert. Diese Vorgaben können im Dialogfeld Konfiguration für Testgenerierung geändert werden. Klicken Sie zum Öffnen des Dialogfelds im Dialogfeld Generieren von Komponententest auf Konfigurieren.

Weitere Informationen finden Sie unter Gewusst wie: Generieren eines Komponententests.

Schreiben von Komponententests

Sie können einen Komponententest auch von Hand schreiben, ohne das Generierungsfeature zu verwenden. Fügen Sie hierzu am Besten einen Komponententest zu einem Testprojekt hinzu. Auf diese Weise wird eine leere Testmethode erstellt, die keinen Code enthält, jedoch über das [TestMethod()]-Attribut verfügt. Um den Test fertig zu stellen, müssen Sie die zugehörige Quelldatei bearbeiten, die sich in der Projektmappe in einem Testprojekt befindet. Weitere Informationen finden Sie unter Gewusst wie: Erstellen eines Komponententests und unter Struktur von Komponententests.

Das Komponententestframework

Das Komponententestframework stellt eine Vielzahl zusätzlicher Assert-Klassen und anderer Klassen zur Verfügung, mit denen Sie das Schreiben von Komponententests flexibler gestalten können. Weitere Informationen finden Sie in der Dokumentation zum Namespace und zu den in Komponententestframework enthaltenen Typen unter Microsoft.VisualStudio.TestTools.UnitTesting.

Vererbung von Testklassen

Eine Testklasse ist eine mit dem TestClass-Attribut markierte Klasse. Testklassen können ab jetzt Member von anderen Testklassen erben. Dies bedeutet, dass Sie wiederverwendbare Tests in Basistestklassen erstellen können. Abgeleitete Testklassen können Tests von Basistestklassen erben. Durch dieses Feature wird vermieden, dass Testcode doppelt vorhanden ist, und Entwickler erhalten mehr Flexibilität beim Ausführen von Komponententests für Produktionscode.

Eine Testklasse kann nicht von einer Klasse erben, die sich in einer anderen Assembly befindet. Sie können diese Einschränkung auf folgende Weise umgehen:

1. Definieren Sie die Basistestklasse in einer Quellcodedatei, und fügen Sie Projekt A die Datei hinzu.

2. Fügen Sie dieselbe Quellcodedatei einem anderen Projekt hinzu, in diesem Fall Projekt B. Klicken Sie dazu im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt, klicken Sie auf Hinzufügen und auf Vorhandenes Element, und wählen Sie dann die Datei im Dialogfeld Vorhandenes Element hinzufügen aus.

3. Obwohl der Code von Projekt B in eine andere Assembly integriert wird, enthält es die Basistestklasse. Andere Testklassen in Projekt B können von dieser Basistestklasse erben.

Vererbungsbeispiel

Der Produktionscode umfasst zwei Implementierungen: für eine wird ein Microsoft SQL Server-Back-End und für die andere Oracle verwendet. Beide Implementierungen müssen auf die gleiche Weise funktionieren. Sie können eine abstrakte Testklasse mit dem Namen von DBTestSuite erstellen, die den Standardtestcode enthält. Sie können dann die beiden Klassen SQLTestSuite und OracleTestSuite erstellen, die beide von DBTestSuite abgeleitet werden. Die abgeleiteten Klassen müssen lediglich die abstrakte Connect-Methode implementieren. Eine Testklasse stellt dann eine Verbindung mit Microsoft SQL Server und die andere eine Verbindung mit Oracle her.

Darüber hinaus können Sie eine EmptySQLTestSuite-Testklasse erstellen, die von SQLTestSuite abgeleitet wird, um eine leere Microsoft SQL Server-Datenbank zu testen. Um die Leistung zu optimieren, können Sie bestimmte Testmethoden überschreiben, die zum Testen einer leeren Datenbank nicht geeignet sind.

Wenn Sie die Vererbung von Testklassen nutzen, werden im Fenster Testansicht und im Testlisten-Editor die Testmethoden sowohl in Basisklassen als auch in untergeordneten Klassen angezeigt. Um festzustellen, in welcher Klasse ein Test enthalten ist, blenden Sie die Spalte Klassenname oder Vollständiger Klassenname im Testlisten-Explorer ein. Weitere Informationen finden Sie unter Gewusst wie: Anpassen von Testansichten.

Testen von privaten Methoden

Mit Komponententests können Sie nicht nur öffentliche, sondern auch private Methoden testen. Ebenso wie bei öffentlichen Methoden werden Komponententests für private Methoden automatisch erstellt, wenn Sie Tests aus dem Code generieren, den Sie testen möchten. Weitere Informationen finden Sie unter Gewusst wie: Testen einer privaten Methode und unter Verwenden privater Accessoren.

Spezielle Komponententests

In der folgenden Tabelle sind zusätzliche Arten von Komponententests aufgelistet:

Siehe auch

Konzepte

Struktur von Komponententests

Komponententests und C++

Arbeiten mit datengesteuerten Komponententests

Weitere Ressourcen

Arbeiten mit ASP.NET-Komponententests

Arbeiten mit Komponententests für intelligente Geräte

Verwalten von Tests

Ausführen von Tests

Analysieren von Testergebnissen