Um teste unitário tem tudo a ver com testar um método ou 'unidade' de código. Você está testando o menor grupo de lógica e código em seu software.
Mais tarde, quando você se unir a outras unidades, realizará o teste de integração.
Espero que o líder da sua equipe tenha incentivado sua iniciativa e tenha oferecido sugestões alternativas. Você definitivamente tem a ideia certa.
Seu SQL é um código como qualquer linguagem de geração inferior como C # ou Java e deve ser testado como tal. E a verificação e validação pertencem a todos os níveis de teste. Então codificação e instruções SET estão incluídas, mas não necessariamente testadas exclusivamente. Coisas gerais, como terminações de linha ou fechamento, geralmente podem ser usadas apenas com um gancho ou recurso do SCM.
A melhor prática é fazer testes de regressão para garantir que os erros passados não sejam reintroduzidos. Geralmente, os testes são criados ao lado de qualquer resolução do bug. Se esses bugs não forem cobertos por testes de regressão na unidade / integração ou no nível do sistema e, em seguida, forem reintroduzidos, será um problema de equipe, um problema de processo, não um problema individual.
A coisa é ... erros de sintaxe, instruções ausentes ou blocos lógicos dentro de uma 'unidade' normalmente não são testados. Você está testando as entradas e saídas da unidade em diferentes combinações, testando as muitas possibilidades que poderiam ser geradas.
Voltando às instruções SET ausentes - elas ajudam a informar as muitas possibilidades de entrada e saída para teste. Que teste você escreveria que falharia se você estivesse perdendo algum SET escolhido?