É sempre bom não testar um recurso?

Existe algum momento em que você se familiariza tanto com seu idioma / banco de dados / sistema que não há necessidade de testar um novo recurso / configuração / consulta / etc. por testes contidos / simulados antes de implementá-los em seu sistema (especialmente em relação a um recurso que modifica dados)? Ou é sempre essencial testar uma nova consulta por simulação em um ambiente de teste ?

Para especificar mais, é claro que é sempre mais seguro testar. No entanto, existe uma maneira de determinar quando o risco é tão mínimo que os testes não valem o esforço? Outra maneira de frasear isso: quando ou é alguma prática profissional correr um risco medido para implementar um recurso?

Além disso, vamos supor que tudo é feito em backup; portanto, no pior cenário, os dados podem ser restaurados com algum esforço.

Alguém pode citar uma experiência específica e especializada para resolver isso? Inclua referências sempre que apropriado / possível.

Quero começar dizendo que tudo o que faço é o SQL Server, e esses são os exemplos que dou. No entanto, em geral, isso se aplica a qualquer forma de código, independentemente do sistema.

Vamos começar detalhando um pouco isso.

Atualizações

Você tem um sistema e está prestes a atualizar alguns ou todos. Por exemplo, atualizando uma instância do SQL Server 2012 para 2014. Nesse momento, o teste é essencial. Infelizmente, testar todas as partes de um aplicativo pequeno provavelmente não será possível. Nesse ponto, eu faria o que chamaria de teste "funcional". O sistema básico está funcionando. Execute suas tarefas comuns do início ao fim. Não teste todas as opções, apenas o caminho principal.

Ao fazer uma atualização do SQL Server, também há algumas leituras necessárias . Basicamente, você deseja ler a Backward Compatibilityentrada para a nova versão ( aqui é a de 2014 ) e verifique se não possui nada em nenhuma das listas (alterações recentes, alterações de comportamento etc.).

Código da aplicação

Aqui estamos analisando o código do aplicativo novo / alterado (porque é claro que qualquer coisa existente já foi testada, certo?). Nesse caso, tudo deve ser testado. Você deve ter casos de teste configurados com antecedência e executar pelo menos a maioria dos recursos afetados. De preferência, nesse ponto, você também deve solicitar que outra pessoa faça uma verificação semelhante. Esse código estará em vigor, provavelmente por um período bastante longo, e usado por um grande número de pessoas. Você quer ter certeza de que funciona e funciona bem.

Uma das coisas que realmente pode ajudar nisso é gerar um conjunto unit testsfacilmente repetível. Steve Jones recomenda o uso do tSQLt para testar seu código TSQL (só tenho medo do SQL Server). Mas, ao fazer isso, você pode executar rapidamente um conjunto fixo de testes e realmente ajudará no teste de regressão (testando tudo, digamos antes de fazer uma atualização).

Recursos / Configurações

Mais do que alterações no código do aplicativo, você deseja testar novos recursos e alterações na configuração. Se, por exemplo, você decidir começar a trabalhar com índices columnstorepela primeira vez, você precisará testar todos os trechos de código que tocam nas tabelas afetadas. Use os testes de unidade que você gerou para testar seu aplicativo. Esses recursos provavelmente são novos para você (e possivelmente novos na plataforma) e provavelmente terão algumas dicas que você não esperava. Quanto às alterações na configuração, você está falando sobre algo que pode afetar todo o sistema, possivelmente significativamente. A regra geral é testar e testar com cuidado. Existem algumas mudanças que você realmente não verá até entrar em um sistema ativo (possivelmente apenas no seu sistema de produção), mas isso não é desculpa para não experimentá-las primeiro em um ambiente de teste.

Consultas ad hoc que referenciam / afetam os dados do usuário

Quando você tem um código que afeta os dados do usuário, geralmente precisa testá-lo, mesmo e talvez especialmente porque é Ad Hoc. Agora, dito isso, se você estiver executando o mesmo trecho de código repetidamente, apenas com parâmetros diferentes, provavelmente não precisará se preocupar em testar todas as vezes.

Por exemplo, você precisa excluir um ou mais anúncios da tabela AdList a cada trimestre.

DELETE FROM AdList WHERE AdName IN ('January 2015 Ads','February 2015 Ads','March 2015 Ads')

Nesse ponto, você já testou o código (você está apenas alterando as cadeias de caracteres fixas) e provavelmente está bastante seguro apenas executando o código (supondo que você tenha bons backups por precaução).

Uma maneira fácil de testar a DELETE, UPDATEou INSERTé alterá-los para um SELECT e executá-los, confirme se o número e o tipo de linhas que você espera são retornados.

Você pode pensar que não precisa testar SELECTs porque eles realmente não alteram nenhum dado. No entanto, você está executando o código por um motivo, certo? Digamos que você esteja pesquisando seu gerente, que por sua vez entregará esses dados ao gerente e assim por diante. Você faz um teste para garantir que não está obtendo os dados errados (ou impedindo que outros colhem seus dados).

Consultas ad hoc que fazem referência / afetam os dados do sistema

Esta é possivelmente a única exceção à regra "testar tudo". Você está executando consultas de informações nos dados do sistema. O importante aqui é recuperar os dados que você espera. Se a consulta for algo simples (consultar uma visualização do sistema), provavelmente você estará bem desde que tenha verificado o que realmente significa a visualização / colunas. Se a consulta for complexa (digamos, atingindo 3 ou 4 visualizações do sistema com cálculos nas colunas retornadas), convém executar alguns testes apenas para garantir que você recupere os dados esperados.

Sumário

Em resumo, sim, você deseja testar tudo. Se é importante o suficiente para você escrever e executá-lo, é importante o suficiente para você testar. Isso não significa que você precise gastar uma quantidade enorme de tempo testando cada ramo de cada linha de código. Mas algum nível de teste precisa ser feito.

O teste de unidade automatizado é seu amigo aqui. Com o advento de DevOpse Continuous Integrationvocê verá mais e mais aplicativos e métodos para testar seu código de maneira rápida e fácil. É claro que isso exige um bom ambiente de teste e dados para acompanhá-lo, mas essa é uma discussão totalmente diferente.

Eu sei o que você sente, tenho 3 anos trabalhando com o MySQL e, no meu caso, sempre testo as consultas DML que podem modificar ou quebrar qualquer informação em todas as tabelas / bancos de dados / replicação de escravos.

É sempre a maneira mais segura de testar sua consulta antes de executá-la.

Não há como saber se sua consulta pode colocar suas informações de dados em risco. A única maneira é conhecer a estrutura e a configuração do banco de dados, para que você possa identificar facilmente quando uma consulta pode colocar seus dados confidenciais em risco ou não.

Em DELETE, UPDATE, INSERT, você deve sempre tentar usar SELECTprimeiro, se você não tiver certeza de que a informação que você está indo para alterar. Em seleções, sempre tente usar o mesmo tipo de dados para as condições do tipo de dados da coluna; em alguns casos, use EXPLAINpara otimização.