W nUnit możemy sprawdzać, czy funkcja wyrzuciła dany wyjątek. W tSQLt analogicznie istnieje taka możliwość za pomocą procedur
EXPECTEXCEPTION oraz EXPECTNOEXCEPTION. SQL Server oczywiście nie ma jako takich wyjątków, znanych ze świata C#. Mamy za to pojęcie Severity Level. Określa one jak bardzo dany błąd jest poważny. Stwórzmy procedurę, która próbuje użyć nieistniejącej tabeli:

CREATE PROCEDURE DoSomething
AS
BEGIN
		SELECT * FROM NOT_EXISTING_TABLE;

END
GO

Jeśli wykonamy ją w tSQLt, test zakończy się oczywiście niepowodzeniem. Jeśli chcemy zweryfikować, że dowolny błąd został wyrzucony wtedy:

EXEC tSQLt.ExpectException 
EXEC DoSomething;

Metodę ExpectException musimy wykonać przed SUT. Może wydawać się to trochę mało intuicyjne ponieważ w C# zwykle DoSomething wywołujemy jako wyrażenie lambda.
Powyższy kod nie jest jednak dobrą praktyką ponieważ wyłapuje wszystkie błędy. Metoda ExpectException przyjmuje kilka interesujących, opcjonalnych parametrów:

tSQLt.ExpectException 
                     [  [@ExpectedMessage= ] 'expected error message']
                     [, [@ExpectedSeverity= ] 'expected error severity']
                     [, [@ExpectedState= ] 'expected error state']
                     [, [@Message= ] 'supplemental fail message']
                     [, [@ExpectedMessagePattern= ] 'expected error message pattern']
                     [, [@ExpectedErrorNumber= ] 'expected error number']

Zwykle chcemy ustalić przynajmniej ExpectedSeverity, aby wiedzieć jakiego typu błędy są spodziewane i akceptowane.
Druga, analogicnza metoda to ExpectNoException:

EXEC tSQLt.ExpectNoException 
EXEC DoSomething;

Nie trudno domyślić się, że używamy ją w sytuacjach, gdy nie spodziewamy się wyjątku.