As instruções log devem ser testadas?

7

Quando escrevo testes, costumo ignorar as declarações de registro, mas agora me pergunto se estava certo.

Os logs geralmente são ferramentas importantes ao diagnosticar problemas de produção, além disso, pode até haver requisitos para logs, como "registrar todas as interações com o sistema externo, incluindo solicitação e resposta no nível mais alto de detalhes" ou "nunca registrar dados confidenciais desmascarados" .

Pela minha experiência, tais requisitos foram testados pelos testadores funcionais, vasculhando uma pilha de logs com alguns scripts. Mas talvez seja melhor garantir que o registro esteja correto e mais próximo do código - com testes de unidade.

Agora a questão é se os logs devem ser testados com testes de unidade?

Estou perguntando porque sinto que muitas vezes o log de testes de unidade exigiria um esforço considerável porque

  • Frequentemente envolve a análise de fluxo de strings
  • Capturar os logs no caso de teste pode não ser fácil
  • Capturar logs de uma forma que garante que eles não sejam entrelaçados com logs de outras fontes pode ser ainda menos direto

Por outro lado, acredito que a qualidade do registro na aplicação é importante e o teste da unidade pode ser uma maneira de garantir essa qualidade, mas talvez outras formas sejam mais econômicas.

    
por AGrzes 17.12.2018 / 21:21
fonte

4 respostas

10

Sim, você deve testar absolutamente seu registro. Eu disse logging e não logs porque eles não importam muito, já que os logs são um detalhe da implementação.

O que quero dizer é que você deve testar que a ação de logging foi feita. Ou usando um mock, um falso ou qualquer coisa que você gostaria. Você achará muito mais fácil testar esse comportamento, e seu código também ficará mais limpo, pois dependerá do conceito de registro, não dos arquivos de registro concretos. Isso significa que você poderá alterar sua estratégia de registro como um todo, dependendo de qualquer coisa que você queira (dica: teste de ambiente, tosse, registro falso na memória, tosse, declarações fáceis).

Caso você ache que seu log não foi testado "de verdade" (e você irá), entenda que apenas as classes de implementação do conceito de log devem ser testadas "de verdade". Não classes que usam o logger.

Então, agora as classes que usam o falso logger provam que estão usando da maneira que deveriam, e as implementações do logger provam que funcionam.

    
por 18.12.2018 / 00:04
fonte
1

Se o log é um comportamento esperado do seu sistema em teste, eu definitivamente sugeriria escrever testes para ele. Eu não vejo uma razão pela qual você não deveria.

    
por 17.12.2018 / 22:36
fonte
1

sim, você deve testar certos aspectos do seu registro, especialmente se você operar um sistema que precisa atender a certos requisitos de rastreabilidade (quem fez o quê).

os problemas que você declara são válidos. Uma maneira de tornar a vida um pouco mais fácil é usar produtores de "log estruturado" - API fluente ou outra maneira de passar parâmetros para o modelo de linha de log ou para criar linhas de registro. Esses madeireiros estruturados são mais fáceis de testar, simular e stub.

    
por 18.12.2018 / 22:58
fonte
0

Eu concordo com Steve que você deve testar suas interfaces de log para se certificar de que elas se comportam corretamente, mas se eu entendi sua pergunta, você está mais focado em testar a saída de log em si.

Acho que isso depende dos casos de uso, mas no meu caso de uso e domínio, o que os logs capturam é realmente uma "opção de último recurso" para problemas que escapam do teste. Se algum bug passa despercebido e um usuário trava em algum lugar, por exemplo, seu log nos mostra o que o sistema estava fazendo quando caiu, o que reduz significativamente a lista de suspeitos (a menos que a saída do log seja errada / enganosa). provavelmente o que você está tentando evitar, mas isso parece tão fora do caminho para eu testar).

Portanto, parece bastante redundante, no meu caso, testar a produção dos próprios logs, já que em um mundo ideal não precisaríamos deles. Eles são uma medida de último recurso, e têm sido um salva-vidas em alguns contextos (uma vez eu consegui restringir rapidamente que o hardware de um usuário não tinha suporte para SSE 4, mesmo que nós o listássemos em nossos requisitos, procurando em sua tora combinada com os requisitos de hardware, na ausência dos logs, eu poderia ter passado uma semana pulando para frente e para trás com ele para tentar diminuir onde ele caiu). E nós resolvemos isso ao fazer pelo menos o código detectar essa limitação de hardware e reportá-la ao usuário em vez de travar *

Though we had to bear the bad news that he did not pay attention to our minimum hardware requirements; he was using some obscure prototype machine we never heard of which still didn't support SSE 4 in 2013 in spite of having 24 cores and 64 gigs of DRAM. Later, out of sympathy, I actually spent a weekend porting the code to use SSE 2 in those cases to reduce our minimum requirements since I figured he must have invested enormous sums of money for that prototype hardware even though there wasn't a legit business requirement. It made me sad to think a person with such beefy hardware couldn't run our software because of this restriction.

Mas em um mundo ideal, eu não me apoiaria nos logs para essa depuração ad-hoc; todos esses problemas seriam capturados em nossos testes. Mas nem sempre posso depender de nossos testes para isso, especialmente com vários recursos de hardware (quando nossa equipe, incluindo o controle de qualidade, não tem todo o hardware do mundo para testar, mesmo que eles tenham uma ampla variedade). No entanto, testar a saída do log seria um pouco mais demorado, provavelmente com pouco ganho para um problema que, idealmente, deveria ter sido capturado sem os logs.

Para meu domínio (e não espero que todos sejam iguais aqui), tratamos o registro como um "efeito não colateral". Ou seja, não temos funções de teste unitário para garantir que suas implementações escrevam as coisas "corretas" nos logs como parte dos requisitos funcionais, porque isso duplicaria nossos esforços de teste para algo projetado para capturar o que escapa nossos testes. o primeiro lugar. Até mesmo o registro "correto" não é interessante no nosso caso, desde que não seja redundante. Se algum subsistema escrever "Estou fazendo backflips e comendo pizza!" que não descreve, muito bem, o que eles estão realmente fazendo, desde que nenhum outro sistema esteja escrevendo a mesma informação, ainda nos permite rastrear exatamente o que o software estava fazendo antes que ele falhasse ou falhasse.

No entanto, temos testes projetados para garantir que a própria funcionalidade de criação de log funcione e em encadeamentos, além de exceções variadas. Mas isso é separado de testar a saída de registro de cada coisa que utiliza o registro.

    
por 18.12.2018 / 18:34
fonte