Ich versuche, mich mit testgetriebenen Ansätzen vertraut zu machen. Ein Nachteil für mich ist, dass ein großer Teil meines Codes Kontext für das Reporting (PDF-Dokumente, Diagrammbilder) generiert wird. Es ist immer ein komplexer Designer beteiligt und es gibt keinen einfachen Test der Korrektheit. Keine Chance, nur Fragmente zu testen!
Kennst du TDD-Praktiken für diese Situation?
Sie könnten die "Acceptance Test Driven Development" -Technologie verwenden, um die Komponententests zu ersetzen, und validierte Berichte für bekannte Daten, die als Referenzen verwendet werden.
Allerdings liefert diese Art von Test keine feinkörnige Diagnose, wie es Komponententests tun, sie liefern normalerweise nur ein BESTANDEN / SCHLECHT-Ergebnis, und sollten sich die Berichte häufig ändern, müssen die Referenzen neu generiert und erneut validiert werden Gut.
Einige Anwendungen oder Frameworks sind nur vererbungsunfähig, und es gibt wirklich nicht viel, was Sie dagegen tun können.
Ich bevorzuge es, solche Frameworks komplett zu vermeiden, aber wenn man absolut gezwungen ist, mit solchen Problemen umzugehen, kann es hilfreich sein, die gesamte Logik in eine testbare Bibliothek zu extrahieren und nur deklarativen Code im Framework zu lassen.
Die Frage, die ich mir in diesen Situationen stelle, lautet: Woher weiß ich, dass ich es richtig verstanden habe?
Ich habe in meiner Karriere viel Code geschrieben, und fast alles funktionierte beim ersten Mal nicht. Fast jedes Mal, wenn ich zurück gegangen bin und den Code für Refactoring, Featurewechsel, Performance oder Bugfix geändert habe, habe ich es wieder kaputt gemacht. TDD schützt mich vor mir selbst (Gott sei Dank!).
Im Fall von generiertem Code fühle ich mich nicht gezwungen, den Code zu testen. Das heißt, ich vertraue dem Codegenerator. Ich möchte jedoch meine Eingänge für die Codegeneratoren testen. Wie es genau funktioniert, hängt von der Situation ab, aber die allgemeine Herangehensweise ist, sich selbst zu fragen, wie ich es falsch machen könnte, und dann herauszufinden, wie ich sicherstellen kann, dass ich es richtig verstanden habe.
Vielleicht schreibe ich einen automatisierten Test. Vielleicht begutachte ich etwas manuell, aber das ist ziemlich riskant. Vielleicht etwas anderes. Es hängt von der Situation ab.
Um die Antworten von Mark Seemann und Jay Bazuzi etwas anders zu interpretieren:
Ihr Problem besteht darin, dass das Berichts-Frontend ein Datenformat erzeugt, dessen Ausgabe Sie nicht einfach im "verify" -Teil Ihrer Tests überprüfen können.
Der Weg, um mit dieser Art von Problem umzugehen, ist:
Halten Sie einige sehr hohe Integrationstests bereit, die oberflächlich sicherstellen, dass Ihr Backend-Code korrekt in Ihren Front-End-Code eingebunden ist. Normalerweise nenne ich diese Tests "Rauchtests", wie in "Wenn ich den Strom einschalte und es raucht, ist es schlecht".
Suchen Sie nach einer anderen Methode zum Testen Ihres Back-End-Berichtscodes. Testen Sie entweder eine Zwischenausgabedatenstruktur oder implementieren Sie ein alternatives Ausgabe-Front-End, das testfreundlicher ist, HTML, Klartext, was auch immer.
Dies entspricht dem üblichen Problem beim Testen von Web-Apps: Es ist nicht möglich, automatisch zu testen, dass "die Seite richtig aussieht". Aber es genügt zu testen, ob die Wörter und Zahlen in den Seitendaten korrekt sind (mit einem programmatischen Browser-Suchlauf als Mechanisierung und einem Seitenabstreifer), und ein paar oberflächliche Funktionstests (mit Selenium oder Windmill), wenn die Seite kritisch abhängig ist auf Javascript.
Sie könnten versuchen, einen Web-Service für Ihre Berichtsdatenquelle zu verwenden und das zu testen, aber Sie werden keine Unit-Tests für das Rendering haben. Dies ist das exakt gleiche Problem, das Sie beim Testen von Ansichten haben. Sicher, Sie können ein Web-Test-Framework wie Selenium verwenden, aber Sie werden wahrscheinlich kein echtes TDD üben. Du wirst Tests erstellen, nachdem dein Code fertig ist.
Kurz gesagt, benutze den gesunden Menschenverstand. Es macht wahrscheinlich keinen Sinn zu versuchen, das Rendern eines Berichts zu testen. Sie können manuelle Testfälle haben, die ein Tester manuell durchlaufen muss oder einfach die Berichte selbst überprüfen.
Sie können auch ausprobieren: Wie viel Einheit Testabdeckung benötigen Sie? - Die Testivus Antwort "
Ziehen Sie in Erwägung, den Text aus der PDF-Datei zu extrahieren und zu prüfen. Dies wird Ihnen jedoch keine Formatierung geben. Einige pdf-Extraktionsprogramme können die Bilder herausziehen, wenn die Diagramme in der pdf sind.
Angesichts dieser Situation versuche ich zwei Ansätze.
Der Ansatz des Goldenen Meisters. Generieren Sie den Bericht einmal, überprüfen Sie ihn selbst und speichern Sie ihn als "Golden Master". Schreiben Sie einen automatisierten Test, um seine Ausgabe mit dem goldenen Master zu vergleichen, und schlagen Sie fehl, wenn sie sich unterscheiden.
Automatisieren Sie die Tests für die Daten, aber überprüfen Sie das Format manuell. Ich automatisiere Prüfungen für das Modul, das die Berichtsdaten generiert, aber um das Berichtsformat zu überprüfen, erzeuge ich einen Bericht mit fest codierten Werten und überprüfe den Bericht von Hand.
Ich rate Ihnen dringend, nicht den vollständigen Bericht zu erstellen, nur um die Richtigkeit der Daten im Bericht zu überprüfen. Wenn Sie den Bericht (nicht die Daten) prüfen möchten, erstellen Sie den Bericht. Wenn Sie die Daten (nicht das Format) überprüfen möchten, generieren Sie nur die Daten.