it-swarm.com.de

Benötigen wir Protokollierung, wenn wir TDD ausführen?

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

Aber was ist mit der Protokollierung?

Ehrlich gesagt habe ich die Protokollierung in einer Anwendung selten verwendet, es sei denn, es passierte etwas wirklich Kompliziertes. Ich habe jedoch zahlreiche Beiträge gesehen, in denen über die Bedeutung einer ordnungsgemäßen Protokollierung gesprochen wurde.
Abgesehen von der Protokollierung einer Ausnahme konnte ich die tatsächliche Bedeutung der Protokollierung in einer ordnungsgemäß getesteten Anwendung (Einheits-/Integrations-/Abnahmetests) nicht rechtfertigen.

Meine Fragen sind also:

  1. Müssen wir uns anmelden, wenn wir TDD machen? Wird ein fehlgeschlagener Test nicht zeigen, was mit der Anwendung nicht stimmt?
  2. Sollten wir in jeder Methode in jeder Klasse einen Test für den Protokollierungsprozess hinzufügen?
  3. Wenn beispielsweise einige Protokollebenen in der Produktionsumgebung deaktiviert sind, führt dies nicht zu einer Abhängigkeit zwischen den Tests und der Umgebung?
  4. Die Leute sprechen 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.

Gibt es etwas, das ich da draußen vermisse?

42
Songo

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

Dies setzt voraus, dass Sie alle möglichen Tests haben, die Ihre Anwendung benötigt, was selten der Fall ist. Mithilfe von Protokollen können Sie Fehler aufspüren, für die Sie noch keine Tests geschrieben haben.

2) Sollten wir in jeder 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 beispielsweise einige Protokollebenen in der Produktionsumgebung deaktiviert sind, führt dies nicht zu einer Abhängigkeit zwischen den Tests und der Umgebung?

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

"Die Rails-Protokollstufe ist eine Information im Produktionsmodus und ein Debugging in Entwicklung und Test" - http://guides.rubyonrails.org/debugging_Rails_applications.html

Andere Anwendungen verwenden einen ähnlichen Ansatz.

4) Die Leute sprechen 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 eine andere Referenz, um diese Probleme zu untersuchen.

50
FMJaguar

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

Ereignisprotokolle zeichnen Ereignisse auf, die bei der Ausführung eines Systems stattfinden, um einen Prüfpfad bereitzustellen, der zum Verständnis verwendet werden kann die Aktivität des Systems und zur Diagnose von Problemen. Sie sind wichtig, um die Aktivitäten komplexer Systeme zu verstehen, insbesondere bei Anwendungen mit geringer Benutzerinteraktion (z. B. Server Anwendungen) ...

Unabhängig davon, wie die Anwendung getestet wurde und wie gut Ausnahmen protokolliert werden, können die Benutzer 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 orientiert sich die Protokollierung mehr an nterstützung als an der Entwicklung. Nachdem die Anwendung live geschaltet wurde, ist es wünschenswert, dass jemand anderes Fragen von Benutzern bearbeitet, damit sich Programmierer auf die weitere Entwicklung konzentrieren können.

Wenn Sie protokollieren, was die Anwendung tut, kann jemand anderes das Programmverhalten verstehen, ohne sich in den Code zu vertiefen und Entwickler nicht durch Anfragen abzulenken, um zu erklären, was los ist.

34
gnat

Die meisten Antworten konzentrieren sich hier auf den Aspekt der Korrektheit. Die Protokollierung dient jedoch auch einem anderen Zweck: Die Protokollierung kann eine Möglichkeit sein, leistungsrelevante Daten zu erfassen. Selbst wenn das System fehlerfrei funktioniert, kann ein Protokoll erkennen, warum es langsam ist. Selbst bei vollständiger Testabdeckung aller Aspekte kann eine Testsuite nichts sagen.

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

17
johannes
  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 (BEARBEITEN: und - wie in den Kommentaren erwähnt - selbst wenn dies der Fall ist, kann etwas von Ihrer Software unabhängiges verursacht werden ein Unfall); Es ist das gleiche wie zu denken, dass Sie eine Software erstellen können, die absolut keine Fehler aufweist (nicht einmal die NASA kann dies tun). Zumindest müssen Sie mögliche Fehler protokollieren, falls Ihr Programm abstürzt, damit Sie wissen, warum.

  2. Die Protokollierung sollte je nach verwendeter Technologie von einer externen Bibliothek oder einem internen Framework durchgeführt werden. 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, ob jede Methode die Dinge protokolliert, die sie soll.

  3. Die Protokolle sind nicht für Tests gedacht, es sollte keinerlei Abhängigkeit bestehen. Sie müssen die Protokollierung für Tests jedoch nicht deaktivieren, wenn dies für Sie eine Einschränkung darstellt. Die Protokolle sollten jedoch in einer Datei gespeichert werden, die der Umgebung entspricht (Sie sollten eine andere Datei für die Test-, Entwicklungs- und Produktionsumgebung haben 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 erkennen können, wo das Problem tatsächlich liegt.

8
Pierre Arlaud

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

Da Sie nicht wissen können, ob sich Ihr System möglicherweise in seltenen Fällen falsch verhält, ist die Protokollierung ein nützliches Tool, mit dem Sie besser verstehen können, was falsch ist, wenn unvermeidlich etwas schief geht.

Protokollierung und TDD sprechen unterschiedliche Probleme an.

8
Andres F.

Ja, im allgemeinen Fall müssen Sie protokollieren.

Bei der Protokollierung geht es nicht um das Debuggen. OK, bei einem Teil der Protokollierung geht es manchmal um das Debuggen, und 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 konzipierte Protokollierung kann die folgenden Fragen beantworten:

  • Ist die Anwendung noch am Leben und läuft sie? (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 Belastung der Applikation in den letzten 10 Monaten geändert? (Durch Protokollieren der Anzahl der Anforderungen pro Anforderungstyp.)
  • Hat eine unserer Schnittstellen ihre Leistungsmerkmale geändert?
  • Verursacht die neue Version ein anderes Nutzungsmerkmal für einige der Subsysteme?
  • 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 ist eine Funktion, die die Behandlung ebenso verdient wie andere Funktionen.

5
Jens Schauder

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

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

Im Großen und Ganzen diente die meiste Protokollierung, die ich implementiert habe und die ich implementiert gesehen habe, der betrieblichen Fehlerbehebung und nicht dem Debuggen der Entwicklung (obwohl dies hilfreich sein kann). Die Hauptzielgruppe für diese Protokollierung sind die Administratoren und Ops, die Ihre Server ausführen, Personen unterstützen, denen Protokolle zur Analyse gesendet wurden, sowie Kunden, die sich die Protokolle ansehen und herausfinden möchten, was los ist.

Diese Protokolle dienen zur Behebung von Problemen, die hauptsächlich bei Integrationspunkten auftreten. Dies können Netzwerkdienste (Datenbank, Seife usw.), lokale Ressourcen (Festplatte, Speicher usw.), fehlerhafte Daten (Kundeneingabe, fehlerhafte/beschädigte Datenquellen usw.) usw. sein. Ausnahmen erfassen, Fehler protokollieren und sogar informative Protokollierung durchführen (Einstellungen, Konfigurationen usw.) können bei der Fehlerbehebung hilfreich sein.

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

Fügen Sie Tests hinzu, wo immer Sie dies benötigen, um die Protokollierung zu testen. Wenn Sie Ad-hoc-Anrufe zum Abmelden von Informationen haben, sollten diese getestet werden. Wenn Sie jedoch Protokollierung und Protokolltests mithilfe von aspektorientierter Programmierung oder Metaprogrammierung implementieren, kann dies die Testlast verringern.

Wenn beispielsweise einige Protokollebenen in der Produktionsumgebung deaktiviert sind, führt dies 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 ein bestimmtes Umgebungssetup verlassen zu müssen.

4
dietbuddha

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

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

3
JohnB

Nach meiner Erfahrung wird der Anwendung ein hohes Maß an Protokollierung hinzugefügt, wenn wir kein TDD durchführen. Dann wird der Grad der Unsicherheit hoch, daher fügen wir die Protokollierung hinzu, um zu sehen, was los ist.

Während ich bei TDD (oder vielleicht bei jedem Test) viel weniger Protokollanweisungen hinzufüge. 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 ausgehende Protokolle für Funktionen hinzu. Wie ich weiß, wurde dies für die Analyse von Produktionsproblemen als obligatorisch angesehen.

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

2
dbalakirev