Benötigen wir die Protokollierung bei TDD?

40

Wenn wir den Rot-, Grün- und Refaktor-Zyklus durchführen, sollten wir immer den Mindestcode schreiben, um den Test zu bestehen. So wurde mir TDD beigebracht und so beschreiben fast alle Bücher den Prozess.

Aber was ist mit der Protokollierung?

Ehrlich gesagt habe ich selten die Protokollierung in einer Anwendung verwendet, es sei denn, es geschah etwas wirklich Kompliziertes. Ich habe jedoch zahlreiche Posts gesehen, die über die Wichtigkeit einer ordnungsgemäßen Protokollierung sprechen.
Abgesehen von der Protokollierung einer Ausnahme konnte ich die tatsächliche Bedeutung der Protokollierung in einer ordnungsgemäß getesteten Anwendung (Einheiten- / Integrations- / Abnahmetests) nicht rechtfertigen.

Meine Fragen sind also:

  1. Müssen wir uns anmelden, wenn wir TDD machen? Wird ein nicht bestandener Test nicht aufdecken, was mit der Anwendung nicht stimmt?
  2. Sollten wir für jede Methode in jeder Klasse einen Test für den Protokollierungsprozess hinzufügen?
  3. Wenn zum Beispiel einige Protokollebenen in der Produktionsumgebung deaktiviert sind, führt dies dann nicht zu einer Abhängigkeit zwischen den Tests und der Umgebung?
  4. Die Leute reden darüber, wie Protokolle das Debuggen vereinfachen, aber einer der Hauptvorteile von TDD ist, dass ich immer weiß, was aufgrund eines fehlgeschlagenen Tests falsch ist.

Gibt es etwas, das ich dort verpasse?

Songo
quelle
5
Ich denke, die Protokollierung ist der Spezialfall für so viele Regeln. Eine Klasse / Funktion sollte eine Sache und nur eine Sache erledigen ... mit Ausnahme der Protokollierung. Funktionen sollten mit Ausnahme der Protokollierung vorzugsweise rein sein. Und so weiter und so fort. Die Protokollierung verstößt gegen die Regeln.
Phoshi
1
Ist die Protokollierung nicht überwiegend orthogonal zu einer verwendeten SW-Entwicklungsmethode? Vielleicht sollten Sie es einschränken und fragen: Brauchen wir Testfälle für die Protokollierung, wenn Sie TDD ausführen?
Hyde

Antworten:

50

1) Müssen wir uns anmelden, wenn wir TDD machen? Wird ein nicht bestandener Test nicht aufdecken, was mit der Anwendung nicht stimmt?

Dies setzt voraus, dass Sie über alle möglichen Testmöglichkeiten für Ihre Anwendung verfügen, was selten zutrifft. Protokolle helfen Ihnen dabei, Fehler aufzuspüren, für die Sie noch keine Tests geschrieben haben.

2) Sollten wir für jede Methode in jeder Klasse einen Test für den Protokollierungsprozess hinzufügen?

Wenn der Logger selbst getestet wird, muss er nicht in jeder Klasse erneut getestet werden, ähnlich wie bei anderen Abhängigkeiten.

3) Wenn zum Beispiel einige Protokollebenen in der Produktionsumgebung deaktiviert sind, führt dies dann nicht zu einer Abhängigkeit zwischen den Tests und der Umgebung?

Menschen (und Protokollaggregatoren) sind von den Protokollen abhängig, die Tests sollten nicht von ihnen abhängen. In der Regel gibt es mehrere Protokollebenen, einige werden in der Produktion verwendet, und einige zusätzliche Ebenen werden in der Entwicklung verwendet, ähnlich wie:

"Rails Log Level ist Info im Produktionsmodus und Debugging in Entwicklung und Test" - http://guides.rubyonrails.org/debugging_rails_applications.html

Andere Anwendungen verwenden einen ähnlichen Ansatz.

4) Die Leute reden darüber, wie Protokolle das Debuggen erleichtern, aber einer der Hauptvorteile von TDD ist, dass ich immer weiß, was aufgrund eines fehlgeschlagenen Tests falsch ist.

Produktionsfehler haben alle Tests bestanden, daher benötigen Sie möglicherweise einen anderen Verweis, um diese Probleme zu untersuchen.

FMJaguar
quelle
26
Selbst eine perfekt durchgeführte TDD verhindert keine Produktionsprobleme mit Leistung, Systeminteraktion oder Interaktion mit Drittanbietern. Nebenläufigkeitsprobleme lassen sich durch Tests nur schwer vollständig abdecken. Eine 100% ige Testabdeckung "nur" bedeutet, dass 100% Ihres Codes ausgeführt wurden, was nicht in allen Zuständen oder Umgebungen korrekt ist.
Holstebroe
34

Die Protokollierung ist nützlich, um das nicht außergewöhnliche Verhalten einer Anwendung zu erklären :

Ereignisprotokolle zeichnen Ereignisse auf, die bei der Ausführung eines Systems auftreten, um einen Audit-Trail bereitzustellen , mit dem die Aktivität des Systems erfasst und Probleme diagnostiziert werden können. Sie sind wichtig, um die Aktivitäten komplexer Systeme zu verstehen, insbesondere bei Anwendungen mit geringer Benutzerinteraktion (z. B. Serveranwendungen ) ...

Unabhängig davon, wie die Anwendung getestet wurde und wie gut Ausnahmen protokolliert werden, können die Benutzer Folgendes fragen:

Die Ausgabe Ihres Programms ist 0, während wir erwartet haben, dass es 1 ist. Warum ist das so?

Sie müssen protokollieren, um die Anwendungskonfiguration, Parameter und andere Laufzeitdetails zu überprüfen und das (nicht außergewöhnliche) Verhalten zu erläutern.

Aus der obigen Perspektive ist die Protokollierung eher auf die Unterstützung als auf die Entwicklung ausgerichtet. Nach dem Start der Anwendung ist es wünschenswert, andere Benutzer mit Fragen zu beauftragen, damit sich die Programmierer auf die weitere Entwicklung konzentrieren können.

Wenn Sie protokollieren, welche Anwendung ausgeführt wird, kann eine andere Person das Programmverhalten verstehen, ohne sich in den Code einzuarbeiten und die Entwickler durch Aufforderungen zur Erläuterung der Vorgänge abzulenken.

Mücke
quelle
5
+1 für "Protokollierung ist mehr auf Unterstützung ausgerichtet". Wirklich den Nagel auf den Kopf getroffen.
Tibos
1
+1 für "nicht außergewöhnliches Verhalten" und auch für "Protokollierung ist mehr auf Unterstützung ausgerichtet". Aber können Sie bitte Ihre Antwort bearbeiten, um die Quelle des von Ihnen zitierten Absatzes aufzulisten?
Logc
Die @logc-Quelle des Zitats wird durch den Link im allerersten Wort hier, "Logging" (Protokollierung), angegeben. Wenn Sie darauf klicken, gelangen Sie zu Wikipedia-Artikel: en.wikipedia.org/wiki/Logfile
gnat
16

Die meisten Antworten konzentrieren sich hier auf den Aspekt der Korrektheit. Die Protokollierung dient jedoch auch einem anderen Zweck: Mit der Protokollierung können leistungsrelevante Daten erfasst werden. Selbst wenn das System fehlerfrei arbeitet, kann ein Protokoll erkennen, warum es langsam ist. Selbst bei vollständiger Testabdeckung aller Aspekte wird eine Testsuite dies nicht verraten.

Natürlich kann / sollte ein leistungskritisches System einige wichtige Leistungsmetriken für ein operatives Dashboard bereitstellen, aber die "klassische" Protokollierung kann einen anderen Detaillierungsgrad bieten.

johannes
quelle
2
Vergessen Sie auch nicht die Protokollierung für Audit-Trail-Zwecke. Oder Abrechnung. Oder verschiedene Arten von Statistiken. Oder Ereignisprotokollierung zum Abgleichen mit anderen Arten von Statistiken anderer Systeme.
PlasmaHH
Ist die Profilerstellung nicht etwas, was Sie ohne Protokollierung tun würden? Oder meinen Sie nur, dass Sie die Profilerstellungsergebnisse kontinuierlich protokollieren könnten?
Bergi
@Bergi: hängt ganz davon ab, wie Ihre Anwendung funktioniert. Wenn es sich beispielsweise um eine Webanwendung handelt, funktioniert es möglicherweise auch, die Servicezeit jeder Anforderung zu protokollieren und später zu versuchen, diese Ereignisse für "schlechte Darsteller" zu gruppieren.
PlasmaHH
@Bergi Profilierung geschieht in der Entwicklung, aber es gibt Auswirkungen auf die Live - Systeme e im Auge behalten, Scheiben mit langsam werden kann, kann die CPU mehr geladen werden, Dienste reagiert unter Umständen nicht in der Zeit, könnten parallele Threads in Verriegelungs Probleme laufen ...
johannes
Die Prüfung von @PlasmaHH ist Teil der Kernanforderungen und muss durch Tests abgedeckt werden. In den meisten Fällen führe ich es nicht über "normale" Protokollierungsrouten aus. Die normale Protokollierung schlägt möglicherweise fehl, die Überwachung jedoch nicht. "verschiedene statistiken" habe ich unter performance gesammelt;)
johannes
8

Die kurze Antwort auf Ihre Hauptfrage lautet: In der Regel werden Fehler in Ihrem Code von TDD NICHT aufgedeckt. Einige mögen, idealerweise viele, aber das Fehlen fehlgeschlagener Tests impliziert nicht das Fehlen von Fehlern. Dies ist eine sehr wichtige Maxime beim Testen von Software.

Da Sie nicht wissen können, ob in Ihrem System ein fehlerhaftes Verhalten vorliegt, ist die Protokollierung unter Umständen unter seltenen Umständen ein nützliches Tool, mit dem Sie besser verstehen können, was falsch läuft, wenn unvermeidlich etwas schief geht.

Protokollierung und TDD gehen unterschiedliche Probleme an.

Andres F.
quelle
7
  1. Wenn Sie nicht über eine 100% ige Testabdeckung verfügen, was normalerweise nicht der Fall ist, können Sie nicht wissen, dass Ihre Software niemals abstürzt (EDIT: und - wie in den Kommentaren erwähnt - auch wenn dies der Fall ist - kann dies zu Problemen führen, die von Ihrer Software unabhängig sind ein Unfall); Es ist das Gleiche wie zu denken, man könne eine Software machen, die absolut keine Fehler aufweist (nicht einmal die NASA kann dies). Zumindest müssen Sie also mögliche Fehler protokollieren, falls Ihr Programm abstürzt, damit Sie wissen, warum.

  2. Die Protokollierung sollte je nach verwendeter Technologie durch eine externe Bibliothek oder ein internes Framework erfolgen. Damit meine ich, dass es etwas sein sollte, das bereits zuvor getestet wurde und dass Sie sich nicht selbst testen müssen. Es ist übertrieben zu testen, dass jede Methode die Dinge protokolliert, die sie haben soll.

  3. Die Protokolle sind nicht für Tests gedacht, es sollte überhaupt keine Abhängigkeit geben. Das heißt, Sie müssen die Protokollierung für Tests nicht deaktivieren, wenn dies für Sie eine Einschränkung darstellt. Die Protokolle sollten jedoch in einer der Umgebung entsprechenden Datei gespeichert werden (für die Test-, Entwicklungs- und Produktionsumgebung sollte eine andere Datei vorhanden sein) zumindest).

  4. Ein Fehler kann sehr unklar sein und es ist nicht immer offensichtlich, was schief gelaufen ist, wenn ein TDD-Test fehlgeschlagen ist. Protokolle sollten genauer sein. Wenn Sie beispielsweise einen Sortieralgorithmus ausführen und der gesamte Testfall fehlschlägt, sollten Sie für jeden einzelnen Test des Algorithmus Protokolle haben, mit denen Sie leichter erkennen können, wo das Problem tatsächlich liegt.

Pierre Arlaud
quelle
3
Selbst wenn Sie eine 100% ige Abdeckung haben, haben Sie diese für alles, was passieren kann? Was ist, wenn die Netzwerkverbindung zu Ihrer Datenbank unterbrochen wird? Werden Ihre Tests Ihnen das sagen?
Zachary K
Sie können nie wissen, dass Ihre Software niemals abstürzt, AUCH wenn Sie 100% ige Abdeckung haben. Eine 100% ige Abdeckung ist zwar wünschenswert, gibt jedoch viel weniger Informationen über die Richtigkeit, als es den Anschein hat.
Andres F.
Ja, da hast du auch Recht. Der Punkt ist, dass es nicht machbar ist, keine Absturzmöglichkeit zu haben. Ich werde bearbeiten.
Pierre Arlaud
1
Die Bearbeitung ist immer noch falsch. Selbst wenn Sie 100% Testabdeckung haben, kann es einen Fehler in Ihrem Code geben (keine Notwendigkeit, externe Ursachen zu beschuldigen). Tests implizieren KEINE Code-Arbeit. Das einzige, was sie mit Sicherheit implizieren, ist, dass Sie keinen Test geschrieben haben, der einen Fehler findet :) Die Testabdeckung ist eine wichtige Messgröße, hängt jedoch nicht direkt mit dem Fehlen von Fehlern zusammen.
Andres F.
3
Es ist trivial zu beweisen, dass "100% Testabdeckung, die besteht! = Fehlerfrei". Gegenbeispiel: add(x, y) = 2(liefert immer 2). Der folgende Test bestanden und bietet eine vollständige Abdeckung: assert(2 == add(1,1)). 100% Testabdeckung für eine Buggy-Funktion :)
Andres F.
5

Ja, im Allgemeinen müssen Sie protokollieren.

Bei der Protokollierung geht es nicht um das Debuggen. Okay, bei einem Teil der Protokollierung geht es manchmal um das Debuggen. Sie können diesen Teil überspringen, wenn Sie ihn während der Entwicklung nicht benötigen.

Der wichtigere Teil der Protokollierung ist jedoch die Wartbarkeit. Eine gut durchdachte Protokollierung könnte die folgenden Fragen beantworten:

  • Lebt die Anwendung noch? (Durch Protokollieren eines Herzschlags alle 1000 Sekunden.)
  • Hat sich die Leistung der Anwendung in den letzten 10 Monaten geändert? (Durch Protokollieren von Statistiken zur Leistung von Anwendungsfällen.)
  • Hat sich die Auslastung der Anwendung in den letzten 10 Monaten geändert? (Durch Protokollieren der Anzahl von Anforderungen pro Anforderungstyp.)
  • Hat eine unserer Schnittstellen ihre Leistungsmerkmale geändert?
  • Verursacht die neue Version bei einigen Subsystemen ein anderes Nutzungsverhalten?
  • Stehen wir unter einem DoS-Angriff ?
  • Welche Fehler treten auf?

All dies kann durch Protokollierung erreicht werden. Und ja, es sollte geplant und entworfen und getestet werden, vorzugsweise automatisch.

Die Protokollierung verdient genau wie andere Funktionen eine Behandlung.

Jens Schauder
quelle
4

TL; DR: Protokollierung und TDD sind orthogonal. Das eine zu haben hat keinen Einfluss darauf, das andere zu brauchen

Müssen wir uns anmelden, wenn wir TDD machen? Wird ein nicht bestandener Test nicht aufdecken, was mit der Anwendung nicht stimmt?

Im Großen und Ganzen diente die Protokollierung, die ich implementiert habe und die ich implementiert gesehen habe, der Fehlerbehebung im Betrieb, nicht dem Debuggen in der Entwicklung (obwohl dies möglicherweise hilfreich ist). Die primäre Zielgruppe für diese Protokollierung sind die Administratoren und Administratoren, die Ihre Server betreiben, Mitarbeiter, denen Protokolle zur Analyse gesendet wurden, und Kunden, die sich die Protokolle ansehen und herausfinden möchten, was los ist.

Diese Protokolle helfen bei der Behebung von Problemen, die hauptsächlich bei Integrationspunkten auftreten. Dies kann Netzwerkdienste (Datenbank, Seife usw.), lokale Ressourcen (Festplatte, Speicher usw.), fehlerhafte Daten (Eingaben des Kunden, fehlerhafte / beschädigte Datenquellen usw.) usw. betreffen (Einstellungen, Konfigurationen usw.) können bei der Fehlerbehebung hilfreich sein.

Sollten wir für jede Methode in jeder Klasse einen Test für den Protokollierungsprozess hinzufügen?

Fügen Sie jederzeit Tests hinzu, um die Protokollierung zu testen. Wenn Sie Ad-hoc-Anrufe zum Abmelden von Informationen haben, sollten diese getestet werden. Wenn Sie die Protokollierung und das Testen von Protokollen mithilfe der aspektorientierten Programmierung oder der Metaprogrammierung implementieren, kann dies den Testaufwand verringern.

Wenn zum Beispiel einige Protokollebenen in der Produktionsumgebung deaktiviert sind, führt dies dann nicht zu einer Abhängigkeit zwischen den Tests und der Umgebung?

Wenn Sie Ihren Code mit IoC schreiben und Mocks verwenden, sollten Sie in der Lage sein, Ihre gesamte Protokollierung effektiv zu testen, ohne sich auf eine bestimmte Umgebungseinrichtung verlassen zu müssen.

dietbuddha
quelle
3

TDD hilft im Allgemeinen dabei, Codierungsfehler zu reduzieren. Es hilft viel weniger bei Fehlern mit der Spezifikation oder nur Missverständnissen darüber, wie die Dinge funktionieren.

"Oh? Sie können eine Datennachricht erhalten, bevor Sie die Bestätigung erhalten, dass die Anmeldung erfolgreich war? Ich wusste das nie, nun, das wird nicht funktionieren!" ... So etwas. Die Protokollierung ist sehr nützlich, um Ihnen mitzuteilen, was die Software versucht hat, damit Sie feststellen können, was Sie falsch gemacht haben.

JohnB
quelle
2

Meiner Erfahrung nach wird der Anwendung ein hohes Maß an Protokollierung hinzugefügt, wenn TDD nicht ausgeführt wird. Dann wird der Grad der Unsicherheit hoch und wir fügen die Protokollierung hinzu, um zu sehen, was los ist.

Wenn ich TDD mache (oder wenn ich es teste), füge ich viel weniger Log-Anweisungen hinzu. Dies bedeutet wiederum weniger LOC und kann (nicht immer) die Leistung beeinträchtigen.

In meinem Unternehmen fügen wir jedoch in den meisten Fällen, unabhängig von der Entwicklungsmethode, halbautomatisch Ein- und Ausstiegsprotokolle für Funktionen hinzu. Wie ich weiß, wurde dies für die Analyse von Produktionsproblemen als obligatorisch angesehen.

Beispiel könnten Methoden eines EJB-Service-Beans sein, die auf der öffentlichen Schnittstelle vorhanden sind. Ein anderer Fall könnte sein, wenn eine Funktion komplexe Berechnungen durchführt. Es kann sehr hilfreich sein, dass Zahlen in die Methode eingegeben werden (z. B. können Sie einen Komponententest schreiben, um zum allgemeinen Thema zurückzukehren).

dbalakirev
quelle
Könnten Sie bitte die Gründe erläutern, warum Sie Protokolle für das Eintreten und Verlassen von Funktionen hinzufügen? Warum ist dies in Ihrem Unternehmen erforderlich?
gnat
ja absolut. Ich hoffe, es ist jetzt besser.
Dbalakirev