Já estou pensando nisso há muito tempo.
A questão básica é: como testar unitariamente procedimentos armazenados?
Vejo que posso configurar testes de unidade com relativa facilidade para funções no sentido clássico (quero dizer, elas obtêm zero ou mais argumentos e retornam um valor). Mas se eu considerar um exemplo da vida real de um procedimento aparentemente simples inserindo uma linha em algum lugar, com alguns gatilhos fazendo isso e aquilo antes ou depois da inserção, até mesmo definir os limites de uma 'unidade' é bastante difícil. Devo testar apenas o INSERTpróprio? Isso é bastante simples, eu acho – com valor relativamente baixo. Devo testar o resultado de toda a cadeia de eventos? Além da questão de saber se este é um teste de unidade ou não, projetar um teste adequado pode ser um trabalho bastante árduo, com muitos pontos de interrogação adicionais surgindo no caminho.
E então vem o problema de dados em constante mudança. No caso de UPDATEafetar mais do que apenas algumas linhas, cada linha potencialmente afetada deve ser incluída de alguma forma nos casos de teste. Outras dificuldades com DELETEs e assim por diante e assim por diante.
Então, como você testa seus procedimentos armazenados? Existe um limite na complexidade onde fica completamente sem esperança? Quais recursos são necessários para a manutenção?
EDITAR Mais uma pequena pergunta, baseada na resposta de AlexKuznetsov: Ou existe um limite sob o qual é completamente inútil?
Estamos fazendo isso há quase cinco anos e achamos que testar explicitamente as modificações é definitivamente factível, mas é bastante lento. Além disso, não podemos executar facilmente esses testes simultaneamente de várias conexões, a menos que usemos bancos de dados separados. Em vez disso, devemos testar as modificações implicitamente - nós as usamos para construir pelo menos alguns dos dados de teste e verificar se nossas seleções retornam os resultados esperados.
Escrevi um artigo intitulado Fechar essas lacunas: lições aprendidas com o teste de unidade T-SQL , bem como algumas postagens no blog
Em relação à sua pergunta "Existe um limite de complexidade onde fica completamente sem esperança?", módulos complexos precisam de testes muito mais do que simples.
Para simplificar a manutenção, geramos os resultados esperados e os armazenamos em arquivos separados - isso faz uma grande diferença.
Sim, você deve testar toda a cadeia de eventos como uma unidade. Portanto, em seu exemplo com um procedimento que se insere em uma tabela e faz com que vários gatilhos sejam acionados, você deve escrever testes de unidade que avaliam o procedimento para várias entradas. Cada teste de unidade deve ser aprovado ou reprovado dependendo se retorna os valores corretos, altera o estado das tabelas corretamente, cria o email correto e até envia os pacotes de rede corretos se for projetado para fazer isso. Em suma, todos os efeitos da unidade devem ser verificados.
Você está correto, que projetar testes de unidade exige algum trabalho, mas a maior parte desse trabalho deve ser feito para testar manualmente a unidade, você está apenas salvando o trabalho necessário para testar a unidade para que, quando uma alteração for feita no futuro, o teste pode ser tão completo e significativamente mais fácil.
A alteração de dados torna o teste mais difícil, mas não torna o teste menos importante e, na verdade, aumenta o valor do teste de unidade, pois a maioria das dificuldades só precisa ser pensada uma vez, e não sempre que uma alteração é feita na unidade. Conjuntos de dados salvos, inserções/atualizações/exclusões que fazem parte da configuração/desmontagem e operação de escopo restrito podem ser usados para facilitar isso. Como a pergunta não é específica do banco de dados, os detalhes variam.
Não há limite de complexidade na extremidade alta ou baixa que deve impedi-lo de testar ou testar a unidade. Considere estas perguntas:
Suponha que você inicie um novo trabalho e tenha a tarefa de otimizar uma pequena função usada em muitos lugares. Todo o aplicativo foi escrito e mantido por um funcionário que ninguém se lembra. As unidades têm documentação que descreve o comportamento normal esperado, mas pouco mais. Qual desses você prefere encontrar?
Para PostgreSQL, confira pgTAP :
Se você preferir que seu teste dos procedimentos armazenados seja feito inteiramente em SQL, dê uma olhada em http://tsqlt.org/
É compatível com MS SQL 2005 SP2 e superior, e a vantagem é que os desenvolvedores não precisam conhecer C# ou outra linguagem para implementar os testes.
Também há recursos para fazer tabelas e visualizações simuladas para ajudá-lo a obter um conjunto de testes executável novamente.
Na prática, o "teste de unidade" no SQL tem pouco valor quando comparado ao valor dos testes funcionais reais que executam o procedimento armazenado ou função da maneira pretendida e, em seguida, examinam o resultado. Muitas vezes, isso significa executar os testes em dados e sistemas próximos da produção.
Os testes de unidade podem facilmente encobrir um problema que está na lógica. Para procedimentos e funções muito simples que têm muito pouca lógica neles e não são entre bancos de dados, os testes de unidade são bons. O padrão-ouro deve ser os testes funcionais. Eu teria dificuldade em escrever, por exemplo, um teste de unidade para um trabalho que lida com testes de orquestração complexos, como sincronizar a segurança do usuário em vários bancos de dados.
No final das contas, os testes de unidade criam MUITO código - código que deve ser mantido - e não oferecem o mesmo valor que um teste de função que realmente testa o resultado correto de um procedimento ou série de procedimentos.
Escrever testes funcionais também cria código que deve ser mantido, mas também fornece código que a maioria dos desenvolvedores e DBAs entendem. Sem intenção de ofender, mas o t-sqlt não é tão intuitivo de usar e tem falhas em procedimentos entre bancos de dados - falhas que resultam em ainda mais código sendo gerado (código que deve ser mantido).
Menos código é melhor. Código que é mais impactante é melhor. Os testes de unidade são populares no mundo dos desenvolvedores e também se espalharam no mundo do desenvolvimento SQL, mas, em última análise, se o seu procedimento SQL para adicionar um usuário a um banco de dados estiver falhando, é muito fácil escrever um teste de unidade para ele que não revelar a ruptura.
Testes rigorosos e funcionais que colocam um procedimento à prova são os melhores, testes de integração para trabalhos que lidam com dados críticos de negócios são obrigatórios .