Verwenden von Transact-SQL-Assertionen in SQL Server-Komponententests

In einem SQL Server-Komponententest wird ein Transact-SQL-Testskript ausgeführt, von dem ein Ergebnis zurückgegeben wird. In einigen Fällen werden die Ergebnisse als Resultset zurückgegeben. Sie können die Ergebnisse mithilfe von Testbedingungen überprüfen. Beispielsweise können Sie eine Testbedingung verwenden, um zu überprüfen, wie viele Zeilen in einem bestimmten Resultset zurückgegeben wurden, bzw. um zu ermitteln, wie lange ein bestimmter Test gedauert hat. Weitere Informationen zu Testbedingungen finden Sie unter Verwenden von Testbedingungen in SQL Server-Komponententests.

Anstelle von Testbedingungen können Sie auch Transact-SQL-Assertionen verwenden. Dabei handelt es sich um THROW- oder RAISERROR-Anweisungen in einem Transact-SQL-Skript. Unter bestimmten Bedingungen ist eine Transact-SQL-Assertion einer Testbedingung vorzuziehen.

Verwenden von Transact-SQL-Assertionen

Bevor Sie entscheiden, ob Sie Daten mithilfe von Transact-SQL-Assertionen oder mithilfe von Testbedingungen überprüfen möchten, sollten Sie die folgenden Punkte überdenken.

• Leistung. Sie sparen Zeit, wenn Sie eine Transact-SQL-Assertion auf dem Server ausführen, anstatt Daten zuerst auf einen Clientcomputer zu verschieben und lokal zu bearbeiten.

• Vertraute Programmiersprache: Abhängig von Ihrem Kenntnisstand ziehen Sie möglicherweise eine bestimmte Programmiersprache vor und geben deshalb Transact-SQL-Assertionen bzw. Visual C#- oder Visual Basic-Testbedingungen den Vorzug.

• Komplexe Überprüfung: In einigen Fällen können Sie in Visual C# oder Visual Basic komplexere Tests erstellen und die Tests auf dem Client überprüfen.

• Einfachheit: Häufig ist es einfacher, eine vordefinierte Testbedingung zu verwenden, anstatt ein gleichwertiges Skript in Transact-SQL zu schreiben.

• Ältere Überprüfungsbibliotheken: Wenn Sie bereits über Code verfügen, durch den eine Überprüfung ausgeführt wird, können Sie ihn in einen SQL Server-Komponententest übernehmen, anstatt Testbedingungen zu verwenden.

Kennzeichen von Komponententestmethoden mit der erwarteten Ausnahme

Um eine SQL Server-Komponententestmethode mit erwarteten Ausnahmen zu kennzeichnen, fügen Sie das folgende Attribut hinzu:

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

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

Hierbei gilt:

• 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 festgelegte Parameter werden ignoriert. Sie übergeben diese Parameter an die RAISERROR-Anweisung im Datenbankcode. Wenn Sie MatchFirstError = true angeben, entspricht das Attribut jedem SqlError in der Ausnahme. Das Standardverhalten („MatchFirstError = true“) besteht darin, dass nur der erste aufgetretene Fehler vom Attribut verglichen wird.

Ein Beispiel dafür, wie erwartete Ausnahmen und ein negativer SQL Server-Komponententest verwendet werden, finden Sie unter Exemplarische Vorgehensweise: Erstellen und Ausführen eines SQL Server-Komponententests.

Die RAISERROR-Anweisung

Hinweis

Verwenden Sie THROW anstelle von RAISERROR. RAISERROR ist mittlerweile veraltet.

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

RAISERROR (@ErrorMessage, @ErrorSeverity, @ErrorState)

Dabei gilt:

@ErrorMessage steht für eine beliebige benutzerdefinierte Fehlermeldung. Sie können diese Meldungszeichenfolge ähnlich wie die printf_s-Funktion formatieren.

@ErrorSeverity ist ein benutzerdefinierter Schweregrad zwischen 0 und 18.

Hinweis

Ein Schweregrad vom Wert „0“ und „10“ führt nicht dazu, dass beim SQL Server-Komponententest ein Fehler auftritt. Sie können einen beliebigen anderen Wert im Bereich von 0 bis 18 eingeben, der dazu führt, dass der Test fehlschlägt.

@ErrorState ist eine willkürliche ganze Zahl zwischen 1 und 127. Sie können diese ganze Zahl verwenden, um Vorkommen eines einzelnen Fehlers zu unterscheiden, die an verschiedenen Stellen im Code vorkommen.

Weitere Informationen finden Sie unter RAISERROR (Transact-SQL). Ein Beispiel zur Verwendung von RAISERROR in einem SQL Server-Komponententest finden Sie im Thema Gewusst wie: Schreiben eines SQL Server-Komponententests, der im Gültigkeitsbereich einer einzelnen Transaktion ausgeführt wird.

Weitere Informationen

Erstellen und Definieren von SQL Server-Komponententests
Verwenden von Testbedingungen in SQL Server-Komponententests
Überprüfen des Datenbankcodes mithilfe von SQL Server-Komponententests
Vorgehensweise: Öffnen eines SQL Server-Komponententests zur Bearbeitung