Verwenden von Transact-SQL-Assertionen in Datenbankkomponententests

Bei einem Datenbankkomponententest wird ein Transact-SQL-Testskript ausgeführt, das ein Ergebnis zurückgibt. In einigen Fällen werden die Ergebnisse als Resultset zurückgegeben. Sie können die Ergebnisse mithilfe von Testbedingungen überprüfen. Sie können z. B. mithilfe einer Testbedingung überprüfen, wie viele Zeilen in einem bestimmten Resultset zurückgegeben wurden oder wie lange die Ausführung eines bestimmten Tests gedauert hat. Weitere Informationen zu Testbedingungen finden Sie unter Verwenden von Testbedingungen in Datenbankkomponententests.

Anstelle von Testbedingungen können Sie auch Transact-SQL-Assertionen verwenden, bei denen es sich um RAISERROR-Anweisungen in einem Transact-SQL-Skript handelt. In bestimmten Situationen möchten Sie möglicherweise anstelle einer Testbedingung eine Transact-SQL-Assertion verwenden.

Verwenden von Transact-SQL-Assertionen

Vor der Entscheidung, ob Sie die Daten mit Transact-SQL-Assertionen oder mit Testbedingungen überprüfen, sollten Sie die folgenden Punkte berücksichtigen.

• Leistung. Die Ausführung einer Transact-SQL-Assertion auf dem Server erfolgt schneller als das Verschieben der Daten auf einen Clientcomputer mit anschließender lokaler Bearbeitung.

• Vertrautheit mit der Sprache. Möglicherweise bevorzugen Sie aufgrund Ihrer Erfahrungen eine bestimmte Programmiersprache und entscheiden sich daher für Transact-SQL-Assertionen oder für C#- bzw. Visual Basic-Testbedingungen.

• Komplizierte Validierung. In bestimmten Fällen können Sie C# oder Visual Basic eine komplexere Testvalidierung erstellen und dann die Tests auf dem Client validieren.

• Vorhandene Validierungsbibliotheken. Wenn Sie bereits über Code für die Validierung verfügen, können Sie diesen in einem Datenbankkomponententest anstelle von Testbedingungen verwenden.

Markieren von Komponententestmethoden mit der erwarteten Ausnahme

Fügen Sie zum Markieren einer Methode für Datenbankkomponententests mit erwarteten Ausnahmen das folgende Attribut hinzu:

<ExpectedSqlException(MessageNumber=nnnnn, Severity=x, MatchFirstError=false, State=y)> _

[ExpectedSqlException(MessageNumber=nnnnn, Severity=x, MatchFirstError=false, State=y)]

Dabei ist:

• nnnnn ist die Nummer der erwarteten Meldung, z. B. 14025.

• x ist der Schweregrad der erwarteten Ausnahme.

• y ist der Zustand der erwarteten Ausnahme.

Nicht angegebene Parameter werden ignoriert. Diese Parameter werden an die RAISERROR-Anweisung im Datenbankcode übergeben. Wenn Sie MatchFirstError = true angeben, stimmt das Attribut mit beliebigen SqlErrors in der Ausnahme überein. Mit dem Standardverhalten (MatchFirstError = true) wird nur der erste auftretende Fehler überprüft.

Ein Beispiel zum Verwenden von erwarteten Ausnahmen und negativen Datenbankkomponententests finden Sie unter Exemplarische Vorgehensweise: Erstellen und Ausführen eines Datenbankkomponententests.

Die RAISERROR-Anweisung

Sie können Transact-SQL-Assertionen direkt auf dem Server verwenden, indem Sie im Transact-SQL-Skript die RAISERROR-Anweisung verwenden. Die Syntax lautet:

**RAISERROR (@ErrorMessage, @ErrorSeverity, @ErrorState)**

Dabei gilt:

@ErrorMessage ist eine beliebige benutzerdefinierte Fehlermeldung. Sie können diese Meldungszeichenfolge wie die printf_s-Funktion formatieren.

@ErrorSeverity ist ein benutzerdefinierter Schweregrad zwischen 0 und 18.

@ErrorState ist eine beliebige ganze Zahl von 1 bis 127. Mithilfe dieser Ganzzahl können Sie zwischen dem Auftreten eines bestimmten Fehlers unterscheiden, der an verschiedenen Stellen im Code ausgelöst wird.

Weitere Informationen finden Sie in der SQL Server-Onlinedokumentation der Microsoft-Website unter RAISERROR (Transact-SQL)). Ein Beispiel für die Verwendung von RAISERROR in einem Datenbankkomponententest finden Sie im Thema Gewusst wie: Schreiben eines Datenbankkomponententests, der innerhalb des Bereichs einer einzelnen Transaktion ausgeführt wird.

Siehe auch

Aufgaben

Gewusst wie: Öffnen eines Datenbankkomponententests zum Bearbeiten

Konzepte

Verwenden von Testbedingungen in Datenbankkomponententests

Überprüfen von Datenbankcode mithilfe von Komponententests