Se você é um administrador de banco de dados (DBA) que trabalha com equipes de desenvolvimento que seguem metodologias ágeis como Scrum ou Agile, é provável que esteja familiarizado com os conceitos de refatoração e desenvolvimento orientado a testes (TDD). Refatoração é o processo de melhorar a estrutura interna do código sem alterar seu comportamento externo, enquanto o TDD envolve escrever testes antes de escrever o código e executar esses testes com frequência para garantir que o código se comporte conforme o esperado.
No entanto, quando se trata de bancos de dados, fazer alterações pode ser arriscado, pois pode afetar os dados. É aí que a ideia de desenvolvimento orientado a testes para bancos de dados se torna atraente. Mas como realizar testes de unidade em T-SQL?
Neste artigo, vamos explorar uma ferramenta chamada TSQLUnit, que segue a abordagem do NUnit para testes de unidade e permite que você escreva testes para stored procedures, funções, triggers e views. Também discutiremos a geração de código usando o CodeSmith para automatizar o processo de escrita de procedimentos de teste.
Pressuposições
Antes de entrarmos em detalhes, vamos estabelecer algumas pressuposições. Este artigo pressupõe que você tenha conhecimento em T-SQL, TSQLUnit, C# e CodeSmith. Além disso, estaremos focando em testar stored procedures existentes, em vez de novos desenvolvimentos.
Criando um Modelo
O primeiro passo é gerar uma lista de stored procedures do banco de dados. O CodeSmith fornece um Schema Explorer que permite que você obtenha informações sobre objetos do banco de dados. Usando isso, você pode iterar pela lista de stored procedures e seus parâmetros.
Em seguida, precisamos criar um modelo para o procedimento de teste. Declaramos uma lista de parâmetros dentro do procedimento de teste que será usada para alimentar o procedimento de aplicação e seus respectivos parâmetros. Também criamos tabelas temporárias para armazenar os resultados esperados e reais da consulta sendo testada.
Definindo Variáveis e Executando o Procedimento
Uma vez que o modelo esteja configurado, precisamos definir as variáveis com valores conhecidos que resultarão nos dados de teste desejados. Geramos a chamada do procedimento para colocar os resultados em uma tabela temporária e, em seguida, verificamos a saída. Verificamos se há erros e, se houver, o teste falha.
Comparando os Resultados
Por fim, precisamos comparar os resultados esperados e reais para garantir que sejam iguais. Podemos criar um procedimento de teste separado para realizar essa comparação.
Conclusão
Ao seguir essa abordagem, podemos gerar scripts para executar testes de unidade em qualquer número de stored procedures em qualquer banco de dados. Isso pode ser extremamente útil ao ajustar o desempenho de stored procedures, pois nos permite demonstrar que o procedimento é executado mais rapidamente, ao mesmo tempo em que retorna os resultados esperados.
Embora este artigo apenas arranhe a superfície do que é possível com código SQL gerado, ele fornece um ponto de partida para implementar testes de unidade em T-SQL. Para obter informações mais detalhadas, recomendo explorar os livros e o site de Scott Ambler sobre técnicas ágeis de banco de dados e refatoração de bancos de dados.
Vale ressaltar que a Microsoft anunciou uma nova versão do Visual Studio para desenvolvedores de banco de dados, que inclui um conjunto completo de recursos de testes de unidade. No entanto, se o preço for uma preocupação, a abordagem descrita neste artigo ainda é uma opção viável.
Agradecimentos especiais a Scott Abrants por sua orientação e assistência no processo de testes de unidade.
Notas de rodapé:
- Martin Fowler, “Refactoring, Improving the Design of Existing Code”, Addison-Wesley, Boston