Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In einem SQL Server-Komponententest wird ein Transact-SQL Testskript ausgeführt und gibt ein Ergebnis zurück. Manchmal werden die Ergebnisse als Resultset zurückgegeben. Sie können Ergebnisse mithilfe von Testbedingungen überprüfen. Sie können z. B. eine Testbedingung verwenden, um zu überprüfen, wie viele Zeilen in einem bestimmten Resultset zurückgegeben wurden, oder um zu überprüfen, wie lange ein bestimmter Test ausgeführt wurde. Weitere Informationen zu Testbedingungen finden Sie unter Verwenden von Testbedingungen in SQL Server-Komponententests.
Statt Testbedingungen zu verwenden, können Sie auch Transact-SQL Assertions nutzen, die THROW oder RAISERROR Anweisungen in einem Transact-SQL Skript sind. Unter bestimmten Umständen sollten Sie eine Transact-SQL Assertion anstelle einer Testbedingung verwenden.
Verwenden von Transact-SQL Assertionen
Sie sollten die folgenden Punkte berücksichtigen, bevor Sie sich entscheiden, Daten entweder mithilfe von Transact-SQL Assertionen oder mithilfe von Testbedingungen zu überprüfen.
Leistung. Es ist schneller, eine Transact-SQL Assertion auf dem Server auszuführen, als zuerst Daten auf einen Clientcomputer zu verschieben und lokal zu bearbeiten.
Vertrautheit mit sprache. Möglicherweise bevorzugen Sie eine bestimmte Sprache basierend auf Ihrer aktuellen Expertise und wählen sie daher Transact-SQL Assertionen oder C# oder Visual Basic Testbedingungen aus.
Komplizierte Überprüfung. In einigen Fällen können Sie komplexere Tests in C# oder Visual Basic erstellen und Ihre Tests auf dem Client überprüfen.
Einfachheit. Häufig ist es einfacher, eine vordefinierte Testbedingung zu verwenden, als das entsprechende Skript in Transact-SQL zu schreiben.
Legacy-Validierungsbibliotheken. Wenn Sie bereits Code haben, der die Überprüfung durchführt, können Sie ihn in einem SQL Server-Komponententest verwenden, anstatt Testbedingungen zu verwenden.
Kennzeichnen von Komponententestmethoden mit der erwarteten Ausnahme
Um eine SQL Server-Komponententestmethode mit erwarteten Ausnahmen zu markieren, 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)]
Ort:
- nnnn ist die Anzahl der erwarteten Nachricht, z. B. 14025
- x ist der Schweregrad der erwarteten Ausnahme.
- y ist der Status der erwarteten Ausnahme.
Alle nicht angegebenen Parameter werden ignoriert. Sie übergeben diese Parameter an die RAISERROR Anweisung im Datenbankcode. Wenn Sie MatchFirstError = true angeben, stimmt das Attribut mit einem der SqlErrors in der Ausnahme überein. Das Standardverhalten (MatchFirstError = true) entspricht nur dem ersten fehler, der auftritt.
Ein Beispiel für die Verwendung erwarteter Ausnahmen und eines negativen SQL Server-Komponententests finden Sie unter Walkthrough: Create and run a SQL Server unit test.
Die RAISERROR-Anweisung
Hinweis
Verwenden Sie THROW anstelle von RAISERROR.
RAISERROR ist jetzt veraltet.
Sie können Transact-SQL Assertionen direkt auf dem Server verwenden, indem Sie die RAISERROR Anweisung in Ihrem Transact-SQL Skript verwenden. Die Syntax sieht wie folgt aus:
RAISERROR (@ErrorMessage, @ErrorSeverity, @ErrorState)
wo:
-
@ErrorMessageist eine beliebige benutzerdefinierte Fehlermeldung. Sie können diese Nachrichtenzeichenfolge ähnlich derprintf_sFunktion formatieren. -
@ErrorSeverityist ein benutzerdefinierter Schweregrad von 0 bis 18.
Hinweis
Die Werte "0" und "10" für den Schweregrad führen nicht dazu, dass der SQL Server-Komponententest fehlschlägt. Sie können einen beliebigen anderen Wert im Bereich 0 bis 18 verwenden, um zu einem Fehler des Tests zu führen.
@ErrorState ist eine beliebige ganze Zahl zwischen 1 und 127. Sie können diese ganze Zahl verwenden, um zwischen Vorkommen eines einzelnen Fehlers zu unterscheiden, der an verschiedenen Stellen im Code ausgelöst wird.
Weitere Informationen finden Sie unter RAISERROR. Ein Beispiel für die Verwendung RAISERROR in einem SQL Server-Komponententest finden Sie im Artikel How to: Write a SQL Server Unit Test that Runs within the Scope of a Single Transaction.