Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Em um teste de unidade do SQL Server, um script de teste Transact-SQL é executado e retorna um resultado. Às vezes, os resultados são retornados como um conjunto de resultados. Você pode validar os resultados usando condições de teste. Por exemplo, você pode usar uma condição de teste para verificar quantas linhas foram retornadas em um conjunto de resultados específico ou para verificar quanto tempo um teste específico levou para ser executado. Para obter mais informações sobre condições de teste, consulte Usar condições de teste em testes de unidade do SQL Server.
Em vez de usar condições de teste, você também pode usar declarações Transact-SQL, que são THROW ou RAISERROR instruções em um script Transact-SQL. Em determinadas circunstâncias, talvez você prefira usar uma declaração Transact-SQL em vez de uma condição de teste.
Usar asserções de Transact-SQL
Você deve considerar os pontos a seguir antes de decidir validar dados usando declarações Transact-SQL ou usando condições de teste.
Desempenho. É mais rápido executar uma declaração Transact-SQL no servidor do que mover os dados primeiro para um computador cliente e manipulá-los localmente.
Familiaridade com a linguagem. Você pode preferir uma linguagem específica com base em sua experiência atual e, assim, escolher asserções do Transact-SQL ou condições de teste em C# ou Visual Basic.
Validação complicada. Em alguns casos, você pode criar testes mais complexos no C# ou no Visual Basic e validar seus testes no cliente.
Simplicidade. Geralmente, é mais simples usar uma condição de teste predefinida do que gravar o script equivalente no Transact-SQL.
Bibliotecas de validação herdadas. Se você já tiver um código que executa a validação, poderá usá-lo em um teste de unidade do SQL Server em vez de usar condições de teste.
Marcar métodos de teste de unidade com a exceção esperada
Para marcar um método de teste de unidade do SQL Server com exceções esperadas, adicione o seguinte atributo:
<ExpectedSqlException(MessageNumber=nnnnn, Severity=x, MatchFirstError=false, State=y)> _
[ExpectedSqlException(MessageNumber=nnnnn, Severity=x, MatchFirstError=false, State=y)]
Where:
- nnnnn é o número da mensagem esperada, por exemplo, 14025
- x é a gravidade da exceção esperada
- y é o estado da exceção esperada
Todos os parâmetros não especificados são ignorados. Você passa esses parâmetros para a instrução RAISERROR em seu código de banco de dados. Se você especificar MatchFirstError = true, o atributo corresponderá a qualquer um dos SqlErrors na exceção. O comportamento padrão (MatchFirstError = true) é corresponder apenas ao primeiro erro que ocorre.
Para obter um exemplo de como usar exceções esperadas e um teste de unidade negativo do SQL Server, consulte Passo a passo: criar e executar um teste de unidade do SQL Server.
A instrução RAISERROR
Observação
Use THROW em vez de RAISERROR.
RAISERROR agora está obsoleto.
Você pode usar diretamente as declarações de Transact-SQL no servidor usando a RAISERROR instrução em seu script Transact-SQL. Sua sintaxe é:
RAISERROR (@ErrorMessage, @ErrorSeverity, @ErrorState)
onde:
-
@ErrorMessageé qualquer mensagem de erro definida pelo usuário. Você pode formatar essa cadeia de caracteres de mensagem semelhante àprintf_sfunção. -
@ErrorSeverityé um nível de severidade definido pelo usuário de 0 a 18.
Observação
Os valores '0' e '10' para o nível de gravidade não fazem com que o teste de unidade do SQL Server falhe. Você pode usar qualquer outro valor no intervalo de 0 a 18 para causar falha no teste.
@ErrorState é um inteiro arbitrário de 1 a 127. Você pode usar esse inteiro para diferenciar as ocorrências de um único erro gerado em locais diferentes no código.
Para obter mais informações, consulte RAISERROR. Um exemplo de como usar RAISERROR em um teste de unidade do SQL Server é fornecido no artigo Como: Escrever um Teste de Unidade do SQL Server que Executa dentro do Escopo de uma Única Transação.