Para quem está acostumado a escrever testes unitários para suas classes e componentes, aqui está um framework interessante para utilizar testes unitários nos objetos de banco de dados do SQL Server. Acredite. Vale muito a pena.
Em meu atual projeto aqui no trabalho tenho conseguido muito sucesso escrevendo minhas tabelas, stored procedures, views e funções com a ajuda de testes unitários com o TSqlUnit. Principalmente tenho encontrado duas razões: design mais consistente e testes de regressão.
Como funciona o TSqlUnit?
A TSqlUnit é um conjunto de stored procedures que fornece uma base para seus casos de testes. Apesar de não muito extensa, o site tem um bom ponto de partida para a instalação e uso básico. Para instalar basta rodar um script que vem junto com o zip baixado no site. Depois você escreve seus casos de teste (em stored procedures) colocando um prefixo ut_ nos seus nomes. Caso alguma condição no seu teste falhe, chame a stored procedure tsu_failure. Por exemplo:
create procedure ut_testarTabelas as
begin
if ( object_id('TabelaQualquer') is null ) begin
exec tsu_failure 'A tabela "TabelaQualquer" deveria existir na base!'
end
end
Vantagens
- Testes de Regressão: este exemplo é interessante porque já ilustra o que os testes unitários podem fazer pelos nossos testes de regressão. Imagine que alguma tabela foi eliminada por engano, ou mesmo imagine o caso mais comum de uma coluna eliminada. Um teste unitário que validasse a existência das tabelas e de suas colunas poderia ser rodado antes de liberar seu código para testes de integração. Não é ótimo?
- Melhor projeto: várias vezes ao escrever e rodar meus testes unitários me deparei com problemas de design das tabelas e principalmente stored procedures. Refazê-las neste ponto do desenvolvimento do projeto onde não há nenhum acoplamento entre a base e aplicações é muito mais seguro e confiável. Imagine se você percebesse um problema de design bem depois de ter seus desenvolvedores usando e abusando dos objetos de banco de dados? E mesmo com os testes unitários, isso vai acontecer! Então porque não minimizá-los?
Desvantagens
No momento a desvantagem é ter que escrever muito código para escrever os casos de testes. Não existe nada pronto que ajude na criação de alguns casos de testes “padrão”. Porém como somos programadores inteligentes e sagazes (segundo Hunt e Thomas, pragmáticos) podemos rapidamente criar ferramentas que gerem testes unitários automáticos.
No meu caso, coloquei a base de dados em um arquivo XML e utilizo transformações XSLT para gerar os vários scripts que necessito. Mas isto é assunto para outro post…
Desenvolvendo Idéias 