Abbiamo bisogno della registrazione quando facciamo TDD?

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

Questo presuppone che tu abbia tutti i test possibili di cui ha bisogno la tua applicazione, il che è raramente vero. I log ti aiutano a rintracciare bug che non hai ancora scritto per test.

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

Se il logger stesso è testato, non dovrebbe essere ritestato in ogni classe, in modo simile ad altre dipendenze.

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

Gli umani (e gli aggregatori di registri) dipendono dai log, i test non dovrebbero dipendere da essi. In genere esistono diversi livelli di registro, alcuni sono utilizzati in produzione e alcuni livelli aggiuntivi sono utilizzati nello sviluppo, in modo simile a:

"Il livello di log delle rotaie è informazioni in modalità di produzione e debug in sviluppo e test" - link

Altre applicazioni usano un approccio simile.

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.

I bug di produzione hanno superato tutti i test, quindi potresti aver bisogno di qualche altro riferimento per indagare su tali problemi.

Registrazione è utile per spiegare comportamento non eccezionale di un'applicazione:

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)...

Indipendentemente dal modo in cui l'applicazione è stata testata e indipendentemente da quanto siano state registrate eccezioni, i suoi utenti potrebbero chiedere,

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

È necessario il log per verificare la configurazione dell'applicazione, i parametri e altri dettagli di runtime per spiegare il suo comportamento (non eccezionale).

Dal punto di vista sopra, la registrazione è più orientata su supporto che sullo sviluppo. Dopo che l'applicazione è stata avviata, è opportuno lasciare che qualcun altro gestisca le domande degli utenti, per consentire ai programmatori di concentrarsi su ulteriori sviluppi.

La registrazione di quale applicazione consente a qualcun altro di comprendere il comportamento del programma senza scavare nel codice e senza distrarre gli sviluppatori dalle richieste di spiegare cosa sta succedendo.

La maggior parte delle risposte qui si concentra sull'aspetto della correttezza. Tuttavia, la registrazione ha anche uno scopo diverso: la registrazione può essere un modo per raccogliere dati pertinenti. Quindi, anche quando il sistema funziona senza errori, un log può dire perché è lento. Anche con una copertura completa del test su tutti gli aspetti che una suite di test non dirà.

Ovviamente un sistema critico per le prestazioni può / dovrebbe fornire parametri di prestazioni chiave per alcuni dashboard operativi, ma la registrazione "classica" può fornire un diverso livello di dettaglio.

La risposta breve alla tua domanda principale è: come regola generale, i bug nel tuo codice NON saranno esposti da TDD. Alcuni potrebbero, idealmente, molti, ma l'assenza di test falliti non implica l'assenza di bug. Questa è una massima molto importante nei test del software.

Dato che non puoi sapere se il tuo sistema avrà un comportamento scorretto, forse in rare condizioni, la registrazione è uno strumento utile che potrebbe aiutare a capire cosa c'è che non va quando le cose inevitabilmente vanno male.

La registrazione e TDD rispondono a preoccupazioni diverse.

1. Se non hai una copertura di prova del 100%, che di solito non è il caso, non puoi sapere che il tuo software non si bloccherà mai (EDIT: e - come detto nei commenti - anche se lo fa, qualcosa indipendente dal tuo software potrebbe causare un arresto anomalo); è come pensare di poter fare un software che non ha assolutamente bug (nemmeno la NASA può farlo). Quindi, per lo meno, è necessario registrare possibili errori nel caso in cui il programma si blocchi in modo da poter sapere perché.

2. La registrazione deve essere eseguita da una libreria esterna o da una struttura interna in base alla tecnologia che si sta utilizzando. Ciò che intendo è che dovrebbe essere qualcosa che è già stato testato prima e che non è necessario testare te stesso. È eccessivo provare che tutti i metodi registrano le cose che dovrebbero.

3. I log non sono pensati per i test, non dovrebbe esserci alcuna dipendenza. Detto questo, non è necessario disabilitare la registrazione per i test se ti sembra un vincolo, anche se i registri dovrebbero essere conservati in un file corrispondente all'ambiente (dovresti avere un file diverso per l'ambiente di test, sviluppo e produzione per lo meno).

4. Un errore potrebbe essere poco chiaro e non è sempre ovvio cosa c'è che non va quando un test TDD fallisce. I registri dovrebbero essere più precisi. Ad esempio, se stai facendo un algoritmo di ordinamento e l'intero caso di test fallisce, dovresti avere i log per ogni singolo test dell'algoritmo che ti aiutano a individuare dove si trova effettivamente il problema.

Sì, nel caso generale è necessario il logging.

La registrazione non riguarda il debug. Bene, OK, una parte del logging a volte riguarda il debugging, e puoi saltare quella parte se non ne hai bisogno durante lo sviluppo.

Ma la parte più importante del logging riguarda la manutenibilità. La registrazione ben progettata potrebbe rispondere alle seguenti domande:

• L'applicazione è ancora viva e vegeta? (Registrando un heartbeat ogni 1000 secondi.)
• Le prestazioni dell'applicazione sono cambiate negli ultimi 10 mesi? (Registrando le statistiche delle prestazioni dei casi d'uso.)
• Il carico dell'applicazione è cambiato negli ultimi 10 mesi? (Registrando il numero di richieste per tipo di richiesta).
• Qualcuna delle nostre interfacce ha cambiato le loro caratteristiche di rendimento?
• Il nuovo rilascio causa una diversa caratteristica di utilizzo verso alcuni sottosistemi?
• Siamo sotto un attacco DoS ?
• Che tipo di errori stanno accadendo?

Tutto ciò può essere ottenuto registrando. E sì, dovrebbe essere pianificato e progettato e testato, automatico preferibile.

La registrazione è una funzionalità che merita il trattamento, proprio come altre funzionalità.

TL; DR: la registrazione e il TDD sono ortogonali. Avere uno non ha alcuna relazione con il bisogno dell'altro

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

La maggior parte del logging che ho implementato e che ho visto implementato è stato per la risoluzione dei problemi operativi, non per il debugging dello sviluppo (sebbene possa essere d'aiuto). Il pubblico principale di questa registrazione sono gli amministratori e gli operatori che gestiscono i server, supportano le persone che hanno i log inviati a loro per l'analisi e i clienti che desiderano esaminare i registri e cercare di capire cosa sta succedendo.

Questi log sono lì per aiutare a risolvere i problemi che riguardano in gran parte i punti di integrazione. Ciò può fare in modo che i servizi di rete (database, sapone, ecc.), Le risorse locali (disco, memoria, ecc.), I dati non validi (input cliente, origini dati danneggiate / danneggiate, ecc.) Catturino eccezioni, errori di registrazione e persino registrazione informativa (impostazioni, configurazioni, ecc.) possono aiutare nella risoluzione dei problemi.

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

Aggiungi test dove mai è necessario per testare la registrazione. Se si dispone di chiamate ad hoc per disconnettere le informazioni, è necessario testarle. Anche se si implementa la registrazione e la verifica dei registri usando Aspect Oriented Programming o meta programmazione, ciò potrebbe ridurre l'onere dei test.

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

Se stai scrivendo il tuo codice usando IoC e fai uso di mock, dovresti essere in grado di testare efficacemente tutto il tuo logging senza fare affidamento su una particolare configurazione ambientale.

TDD generalmente aiuta a ridurre i bug di codifica. Aiuta molto meno con bug con le specifiche o solo equivoci su come funzionano le cose.

"Puoi ottenere un messaggio di dati prima hai la conferma che l'accesso è riuscito? Non l'ho mai saputo, beh, non lo gestirà!" ... Quel genere di cose. La registrazione è molto utile per dirti cosa ha cercato di fare il software in modo da poter individuare la cosa che hai fatto di sbagliato.

Nella mia esperienza, quando non eseguiamo TDD, viene aggiunto un grande livello di registrazione all'applicazione. Quindi il livello di incertezza diventa elevato, quindi aggiungiamo il logging per vedere cosa sta succedendo.

Mentre quando faccio TDD (o forse test-ogni volta) mi ritrovo ad aggiungere molte meno dichiarazioni di log. Ciò a sua volta significa meno LOC e può (non sempre) influire sulle prestazioni.

Ma nella maggior parte dei casi aggiungiamo i log in entrata e in uscita in modo semiautomatico alla mia azienda, indipendentemente dal metodo di sviluppo. Come so, questo è stato considerato obbligatorio per l'analisi dei problemi di produzione.

Esempi potrebbero essere i metodi di un bean di servizio EJB presenti nell'interfaccia pubblica. Un altro potrebbe essere un caso in cui una funzione esegue calcoli complessi. Può essere di grande aiuto avere cifre che entrano nel metodo (ad esempio puoi scrivere un test unitario per tornare all'argomento generale).