Precisamos de registro ao fazer TDD?

1) Do we need to log if we are doing TDD? won't a failing test reveal what wrong with the application?

Isso pressupõe que você tenha todos os testes possíveis que seu aplicativo precisa, o que raramente é verdade. Os registros ajudam você a rastrear bugs dos quais você ainda não escreveu testes.

2) Should we add test for the logging process in each method in each class?

Se o próprio criador de logs for testado, ele não precisará ser testado novamente em cada classe, semelhante a outras dependências.

3) If some log levels are disabled in the production environment for example, won't that introduce a dependency between the tests and environment?

Humanos (e agregadores de registros) dependem dos logs, os testes não devem depender deles. Normalmente existem vários níveis de log, e alguns são usados na produção, e alguns níveis adicionais são usados no desenvolvimento, semelhante a:

"O nível de registro do Rails é info no modo de produção e depuração no desenvolvimento e teste" - link

Outras aplicações usam uma abordagem semelhante.

4) People talk about how logs ease debugging, but one of the main advantages about TDD is that I always know what's wrong due to a failing test.

Erros de produção terão passado em todos os testes, então você pode precisar de alguma outra referência para investigar esses problemas.

Fazer login é útil para explicar comportamento não excepcional de um aplicativo:

Event logs record events taking place in the execution of a system in order to provide an audit trail that can be used to understand the activity of the system and to diagnose problems. They are essential to understand the activities of complex systems, particularly in the case of applications with little user interaction (such as server applications)...

Não importa como o aplicativo foi testado e não importa o quão bem as exceções são registradas, seus usuários podem perguntar,

output of your program is 0 while we expected it to be 1, why is that?

Você precisa de registro para verificar o que foi a configuração do aplicativo, os parâmetros e outros detalhes do tempo de execução para explicar seu comportamento (não excepcional).

Da perspectiva acima, o registro é mais orientado no suporte do que no desenvolvimento. Depois que o aplicativo for ativado, é desejável permitir que alguém manipule perguntas dos usuários, para permitir que os programadores se concentrem em desenvolvimento adicional.

O registro em log de qual aplicativo permite que alguém entenda o comportamento do programa sem entrar no código e sem distrair os desenvolvedores por solicitações para explicar o que está acontecendo.

A maioria das respostas aqui se concentra no aspecto de correção. Mas a criação de log também tem um propósito diferente: o registro em log pode ser uma maneira de reunir dados relevantes de desempenho. Assim, mesmo quando o sistema funciona sem erros, um log pode dizer por que está lento. Mesmo com cobertura de teste completa de todos os aspectos, uma suíte de testes não dirá.

É claro que um sistema de desempenho crítico pode / deve fornecer métricas de desempenho chave para algum painel operacional, mas o registro "clássico" pode fornecer um nível diferente de detalhes.

A resposta curta à sua pergunta principal é: como regra geral, os erros no seu código NÃO serão expostos pelo TDD. Alguns podem, idealmente, muitos, mas a ausência de testes com falha não implica a ausência de erros. Esta é uma máxima muito importante no teste de software.

Como você não pode saber se terá um comportamento incorreto em seu sistema, talvez sob condições raras, o registro em log é uma ferramenta útil que pode ajudar a entender o que está errado quando as coisas inevitavelmente dão errado.

O registro em log e o TDD abordam diferentes preocupações.

1. A menos que você tenha uma capa de teste de 100%, o que geralmente não é o caso, você não pode saber que seu software nunca irá falhar (EDITAR: e - como dito nos comentários - mesmo que isso aconteça, algo independente de seu software pode causar uma falha); é o mesmo que pensar que você pode fazer um software que não tenha absolutamente nenhum bug (nem mesmo a NASA pode fazer isso). Então, no mínimo, você precisa registrar possíveis falhas no caso de o seu programa travar para que você possa saber o motivo.

2. O registro deve ser feito por uma biblioteca externa ou estrutura interna, dependendo da tecnologia que você está usando. O que quero dizer com isso é que deve ser algo que já foi testado antes e que você não precisa se testar. É um exagero testar que todos os métodos registram as coisas que deveriam.

3. Os logs não são destinados a testes, não deve haver dependência alguma. Dito isso, você não precisa desabilitar o log para testes se parecer uma restrição para você, embora os logs devam ser mantidos em um arquivo correspondente ao ambiente (você deve ter um arquivo diferente para o ambiente de teste, desenvolvimento e produção). no mínimo).

4. Um erro pode não ser muito claro e nem sempre é óbvio o que aconteceu de errado quando um teste de TDD falhou. Os logs devem ser mais precisos. Por exemplo, se você estiver fazendo um algoritmo de classificação e todo o caso de teste falhar, você deverá ter logs para cada teste do algoritmo que o ajudará a identificar onde o problema realmente está.

Sim, no caso geral, você precisa de registro.

O registro não é sobre depuração. Bem, OK, uma parte do registro é algumas vezes sobre depuração, e você pode pular essa parte se você não precisar dela durante o desenvolvimento.

Mas a parte mais importante do registro é sobre manutenção. O registro bem projetado pode responder às seguintes perguntas:

• O aplicativo ainda está ativo e funcionando? (Registrando um heartbeat a cada 1000 segundos).
• O desempenho do aplicativo mudou nos últimos 10 meses? (Registrando estatísticas do desempenho de casos de uso.)
• A carga do aplicativo mudou nos últimos 10 meses? (Registrando o número de solicitações por tipo de solicitação).
• Alguma de nossas interfaces mudou suas características de desempenho?
• A nova versão causa uma característica de uso diferente em relação a alguns dos subsistemas?
• Estamos sob um ataque de DoS ?
• Que tipos de erros estão acontecendo?

Tudo isso pode ser alcançado registrando. E sim, deve ser planejado e projetado e testado, preferível automático.

O registro em log é um recurso que merece tratamento, assim como outros recursos.

TL; DR: o registro em log e o TDD são ortogonais. Ter um não tem importância em precisar do outro

Do we need to log if we are doing TDD? won't a failing test reveal what wrong with the application?

Em geral, a maioria dos logging que eu implementei, e que eu vi implementado, foi para solução de problemas operacionais, não para depuração de desenvolvimento (embora possa ajudar). O principal público para esse registro são os administradores e os operadores que administram seus servidores, dão suporte a pessoas que têm registros enviados para análise e clientes que desejam examinar os logs e tentar descobrir o que está acontecendo.

Esses logs estão lá para ajudar na solução de problemas em grande parte dos pontos de integração. Isso pode serviços de rede (banco de dados, sabão, etc), recursos locais (disco, memória, etc), dados inválidos (entrada do cliente, fontes de dados ruins / corruptos, etc), etc. Capturando exceções, registrando falhas e até fazendo log informativo (configurações, configurações, etc) podem ajudar na solução de problemas.

Should we add test for the logging process in each method in each class?

Adicione testes onde você precisar para testar o registro. Se você tiver chamadas ad hoc para efetuar logout, elas deverão ser testadas. Embora se você implementar testes de log e log usando Programação Orientada a Aspectos ou metaprogramação, isso pode reduzir a carga de testes.

If some log levels are disabled in the production environment for example, won't that introduce a dependency between the tests and enviroment?

Se você estiver escrevendo seu código usando o IoC e usar mocks, será possível testar efetivamente todos os seus registros sem depender de uma configuração ambiental específica.

O TDD geralmente ajuda a reduzir erros de codificação. Isso ajuda muito menos com bugs com a especificação ou apenas mal-entendidos sobre como as coisas funcionam.

"Oh? Você pode receber uma mensagem de dados antes receber a confirmação do logon bem-sucedido? Eu nunca soube disso, bem, não vai lidar com isso!" ... Esse tipo de coisa. O registro é muito útil para dizer o que o software tentou fazer para que você possa identificar o que você fez errado.

Na minha experiência, um ótimo nível de registro é adicionado ao aplicativo quando não fazemos TDD. Então o nível de incerteza se torna alto, por isso adicionamos o registro para ver o que está acontecendo.

Considerando que, ao fazer TDD (ou talvez testar-sempre), estou adicionando muito menos instruções de log. Isso, por sua vez, significa menos LOC e pode (nem sempre) afetar o desempenho.

Mas adicionamos registros de entrada e saída para funções de maneira semi-automática na minha empresa na maioria dos casos, independentemente do método de desenvolvimento. Como sei, isso foi considerado obrigatório para a análise de questões de produção.

Exemplo poderia ser métodos de um bean de serviço EJB que estão presentes na interface pública. Outro pode ser um caso quando uma função faz cálculos complexos. Pode ajudar muito ter figuras entrando no método (por exemplo, você pode escrever um teste de unidade para voltar ao tópico geral em mãos).