Quando escrevo testes de unidade para meus procedimentos armazenados, eles geralmente se parecem com isto:
/* Unit test for stored procedure which runs a query */
/* Define #temp table with structure of query results */
/* Define and set variables for stored procedure parameters */
/* If stored procedure queries from a particular table...*/
/* Truncate table and populate with sample data */
/* Call stored procedure using variables but insert results into table */
/* INSERT #temp EXEC usp_TestProc @P1=1, @P2 = 'X' */
/* Query #temp table to confirm that all fields have certain values */
/* Query #temp table to confirm that certain number of rows exist */
/* If results are incorrect, display error message */
Embora isso funcione, parece desajeitado de alguma forma e é muito difícil de manter ao longo de um projeto de longo prazo em que os requisitos mudam constantemente.
- Existe uma maneira melhor (ou padrão) de testar um procedimento armazenado como este?
- A dificuldade de manutenção é simplesmente parte do trabalho e vale o esforço para fazer os testes de unidade? Devo dizer que, na maioria dos meus trabalhos, os DBAs raramente fazem testes de unidade em primeiro lugar.
Escrevi uma série de blogs sobre procedimentos armazenados selecionados de teste de unidade usando DBTestUnit que podem ser úteis.
Use, por exemplo, TST-TSQL Test Tool . Ele automatizará seu processo. Veja outras soluções que pedi no sqa
Sorte.
Eu tenho feito testes de unidade T-SQL por mais de quatro anos até agora. Acho muito mais fácil usar C#, que é mais versátil. Por exemplo, em C# não tenho problema em testar um procedimento armazenado que retorna dois ou mais conjuntos de resultados - é simplesmente impossível se você usar T-SQL. Eu descrevi o processo neste artigo e nesta postagem no blog .