Le dichiarazioni del registro dovrebbero essere testate?

Sì, dovresti assolutamente testare la tua registrazione. Ho detto logging e non log perché non hanno molta importanza, poiché i log sono un dettaglio di implementazione.

Ciò che intendo è che dovresti verificare che l'azione di registrazione sia stata eseguita. O usando un finto, un falso o qualsiasi cosa ti piacerebbe. Troverai molto più semplice testare questo comportamento e il tuo codice sarà anche più pulito poiché dipenderà dal concetto di registrazione, non dai file di registro in modo concreto. Ciò significa che sarai in grado di cambiare la tua strategia di registrazione nel suo complesso a seconda di qualsiasi cosa desideri (suggerimento: ambiente di test, tosse, registrazione fittizia in memoria, tosse, facili asserzioni).

Se pensate che il vostro logging non sia testato "per davvero" (e lo farete), comprendete che solo le classi di implementazione di quel concetto di registrazione dovrebbero essere testate "per davvero". Non classi che usano il logger.

Quindi ora le classi che utilizzano il logger falso dimostrano di usarlo come dovrebbero, e le implementazioni del registratore dimostrano che funzionano.

Se il logging è un comportamento atteso del sistema in prova, suggerirei di scrivere test per questo. Non vedo una ragione per cui non dovresti.

Sì, dovresti testare alcuni aspetti della tua registrazione, specialmente se gestisci un sistema che deve soddisfare determinati requisiti di tracciabilità (chi ha fatto cosa quando).

i problemi che dichiari sono validi Un modo per semplificare la vita è utilizzare i produttori di "log strutturato": API fluente o altro modo per passare i parametri per registrare il modello di linea o per costruire linee di log. Questi logger strutturati sono più facili da testare, simulare e stub.

Sono d'accordo con Steve sul fatto che dovresti testare le tue interfacce di registrazione per assicurarti che si comportino correttamente, ma se ho capito la tua domanda, sei più concentrato nel testare l'output del log stesso.

Penso che dipenda dai casi d'uso, ma nel mio caso d'uso e dominio, ciò che i registri catturano è in realtà una "ultima opzione" per i problemi che sfuggono ai test. Se qualche bug vola sotto il radar e un utente si blocca da qualche parte, ad esempio, il loro registro ci mostra cosa stava facendo il sistema quando si è schiantato che restringe significativamente l'elenco dei sospetti (a meno che, ovviamente, l'output del registro sia errato / fuorviante che è probabilmente quello che stai cercando di evitare, ma sembra così fuori mano per me testare.

Quindi nel mio caso sembra piuttosto ridondante testare l'output dei log stessi, poiché in un mondo ideale non avremmo bisogno di loro. Sono una misura di ultima istanza e sono stati un salvavita in alcuni contesti (una volta sono stato in grado di limitare rapidamente che l'hardware di un utente non supportava SSE 4, anche se lo abbiamo elencato nelle nostre esigenze, cercando al suo registro combinato con i requisiti hardware, in assenza dei registri avrei trascorso una settimana a rimbalzare avanti e indietro con lui per cercare di restringere il punto in cui si era schiantato). E abbiamo risolto il problema, almeno facendo in modo che il codice rilevi quella limitazione hardware e lo segnalassi all'utente invece di andare in crash *

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.

Ma in un mondo ideale non vorrei affidarmi ai log per questo debug ad hoc; tutti questi problemi verrebbero presi nei nostri test. Ma non posso sempre dipendere dai nostri test per questo, specialmente con le diverse capacità hardware (quando il nostro team, incluso il QA, non ha tutto l'hardware al mondo per testarlo, anche se hanno una vasta gamma). Tuttavia, testare l'output del log sarebbe un bel po 'di tempo con probabilmente poco guadagno per un problema che idealmente avrebbe dovuto essere colto in assenza dei log in primo luogo.

Per il mio dominio (e non mi aspetto che tutti siano uguali qui), consideriamo il logging come un "effetto non-laterale". Vale a dire, non eseguiamo test unitari per accertarci che le loro implementazioni scrivano le cose "giuste" ai log come parte dei requisiti funzionali, perché ciò raddoppierà i nostri sforzi di test per qualcosa progettato per catturare ciò che sfugge ai nostri test in il primo posto. Anche la registrazione "corretta" non è interessante nel nostro caso, a condizione che non sia ridondante. Se qualche sottosistema scrive, "Sto facendo backflip e mangiando pizza!" che non descrive, molto bene, quello che stanno effettivamente facendo, purché nessun altro sistema stia scrivendo le stesse informazioni, ci permette comunque di risalire esattamente a ciò che il software stava facendo prima che si bloccasse o glitching.

Tuttavia, disponiamo di test progettati per garantire che la funzionalità di registrazione stessa funzioni, e attraverso i thread e contro diverse eccezioni. Ma questo è separato dal test dell'output di registrazione di ogni singola cosa che utilizza la registrazione.