Wie funktioniert Komponententest, wenn das Programm nicht zu einem funktionalen Stil passt?

8

Ich denke an den Fall, wo das Programm nichts wirklich berechnet, es tut einfach viel. Komponententests sind für mich sinnvoll, wenn Sie Funktionen schreiben, die etwas berechnen, und Sie müssen das Ergebnis überprüfen, aber was ist, wenn Sie nichts berechnen? Zum Beispiel hängt ein Programm, das ich bei der Arbeit aufrechterhalte, davon ab, dass der Benutzer ein Formular ausfüllt, dann ein externes Programm öffnet und das externe Programm automatisiert, um etwas basierend auf der Benutzereingabe zu tun. Der Prozess ist ziemlich involviert. Es gibt ungefähr 3000 Codezeilen (verteilt auf mehrere Funktionen *), aber ich kann mir keine einzige Sache vorstellen, die für einen Komponententest sinnvoll ist.

Das ist nur ein Beispiel. Sollten Sie sogar versuchen, prozedurale Programme zu testen?

* BEARBEITEN

    
Instance Hunter 04.03.2009, 03:09
quelle

10 Antworten

2

Nach Ihrer Beschreibung sind dies die Orte, an denen ich den Unit-Test sehen würde:

  • Funktioniert die Formularvalidierung von Benutzereingaben korrekt?
  • Gegebene Eingabe von dem Formular ist das externe Programm korrekt
  • genannt
  • Geben Sie die Benutzereingabe an das externe Programm weiter und sehen Sie, ob Sie die richtige Ausgabe erhalten haben

Von den Klängen Ihrer Beschreibung her besteht das eigentliche Problem darin, dass der Code, mit dem Sie arbeiten, nicht modular ist. Einer der Vorteile, den ich beim Komponententest feststellen kann, ist, dass Code, der schwer zu testen ist, entweder nicht modular genug ist oder eine schwierige Schnittstelle hat. Versuchen Sie, den Code in kleinere Teile zu zerlegen, und Sie werden Orte finden, an denen es sinnvoll ist, Komponententests zu schreiben.

    
Alex Rockwell 04.03.2009, 03:22
quelle
2

Ich bin kein Experte dafür, bin aber aus dem gleichen Grund eine Zeitlang verwirrt. Irgendwie passen die Anwendungen, die ich gerade mache, nicht zu den Beispielen, die für UNIT-Tests angegeben wurden (sehr asynchron und zufällig, je nach starker Benutzerinteraktion) Ich habe kürzlich festgestellt (und bitte lassen Sie mich wissen, wenn ich falsch liege), dass es keinen Sinn macht, eine Art globaler Test zu machen, sondern eine Vielzahl von kleinen Tests für jede Komponente. Am einfachsten ist es, den Test in der gleichen Zeit oder sogar vor dem Erstellen der eigentlichen Prozeduren zu erstellen.

    
Theo.T 04.03.2009 03:17
quelle
1

Haben Sie 3000 Zeilen Code in einer einzigen Prozedur / Methode? Wenn dies der Fall ist, müssen Sie Ihren Code wahrscheinlich in kleinere, verständlichere Teile umwandeln, um ihn wartbar zu machen. Wenn Sie dies tun, haben Sie die Teile, die Sie testen können und sollten. Wenn nicht, dann haben Sie bereits diese Stücke - die einzelnen Verfahren / Methoden, die von Ihrem Hauptprogramm aufgerufen werden.

Auch ohne Komponententests sollten Sie dennoch Tests für den Code schreiben, um sicherzustellen, dass Sie die richtigen Eingaben für das externe Programm bereitstellen und testen, ob Sie die Ausgaben des Programms unter normalen und außergewöhnlichen Bedingungen korrekt verarbeiten. In diesen Integrationstests können Techniken verwendet werden, die bei Komponententests zum Einsatz kommen - wie zum Beispiel "Mocking", um sicherzustellen, dass Ihr Programm korrekt funktioniert, ohne die externe Ressource einzubeziehen.

    
tvanfosson 04.03.2009 03:18
quelle
1

Ein interessanter "Schnittpunkt" für Ihre Anwendung ist, dass Sie sagen: "Der Benutzer füllt ein Formular aus." Wenn Sie testen möchten, sollten Sie Ihren Code neu strukturieren, um eine explizite Darstellung dieses Formulars als Datenstruktur zu erstellen. Dann können Sie damit beginnen, Formulare zu sammeln und zu testen, ob das System auf jedes Formular angemessen reagiert.

Es kann sein, dass die Aktionen Ihres Systems nicht beobachtet werden können, bis etwas das Dateisystem erreicht. Hier sind ein paar Ideen:

  • Richten Sie etwas wie ein git-Repository für den Anfangszustand des Dateisystems ein, führen Sie ein Formular aus und sehen Sie sich die Ausgabe von git diff an. Es ist wahrscheinlich, dass sich dies mehr wie Regressionstests als Unit-Tests anfühlt.

  • Erstellen Sie ein neues Modul, dessen einziger Zweck es ist, die Aktionen Ihres Programms beobachtbar zu machen. Dies kann so einfach sein wie das Schreiben von relevantem Text in eine Protokolldatei oder so komplex wie Sie möchten. Bei Bedarf können Sie das bedingte Kompilieren oder Verknüpfen verwenden, um sicherzustellen, dass dieses Modul nur dann ausgeführt wird, wenn das System getestet wird. Dies ist näher am traditionellen Komponententest, da Sie nun Tests schreiben können, die beim Empfangen von Form A sagen, das System sollte die Abfolge von Aktionen B nehmen. Offensichtlich müssen Sie entscheiden, welche Maßnahmen zu beachten sind, um einen vernünftigen Test zu bilden.

Ich vermute, Sie werden feststellen, dass Sie zu etwas migrieren, das mehr nach Regressionstests als nach Komponententests aussieht per se . Das ist nicht unbedingt schlecht. Übersehen Sie nicht die Codeabdeckung!

(Eine abschließende Bemerkung in Klammern: In den schlechten Zeiten der interaktiven Konsolenanwendungen hat Don Libes ein Tool namens Expect erstellt, das war Es ist enorm hilfreich, ein Programm zu programmieren, das wie ein Benutzer interagiert. Meiner Meinung nach brauchen wir dringend etwas Ähnliches für die Interaktion mit Webseiten. Ich denke, ich werde eine Frage dazu stellen: -)

    
Norman Ramsey 04.03.2009 03:57
quelle
0

Sie müssen nicht unbedingt automatisierte Tests implementieren, die einzelne Methoden oder Komponenten testen. Sie könnten einen automatisierten Komponententest implementieren, der einen Benutzer simuliert, der mit Ihrer Anwendung interagiert, und testen, ob Ihre Anwendung richtig reagiert.

Ich gehe davon aus, dass Sie Ihre Anwendung derzeit manuell testen. Wenn ja, dann überlegen Sie, wie Sie das automatisieren und von dort aus arbeiten können. Mit der Zeit sollten Sie in der Lage sein, Ihre Tests in immer kleinere Abschnitte zu zerlegen, die kleinere Codeabschnitte testen. Jede Art von automatisierten Tests ist normalerweise viel besser als nichts.

    
tbreffni 04.03.2009 03:21
quelle
0

Die meisten Programme (unabhängig vom Sprachparadigma) können in atomare Einheiten zerlegt werden, die Eingaben aufnehmen und ausgeben. Wie die anderen Responder erwähnt haben, schauen Sie sich das Programm an und zerlegen es in kleinere Teile. Konzentrieren Sie sich beim Testen weniger auf die End-to-End-Funktionalität als auf die einzelnen Schritte, in denen Daten verarbeitet werden.

Auch muss eine Einheit nicht notwendigerweise eine individuelle Funktion sein (obwohl dies oft der Fall ist). Eine Einheit ist ein Funktionsbereich, der über Eingänge und Messausgänge getestet werden kann. Ich habe das gesehen, als ich JUnit zum Testen von Java-APIs verwendet habe. Einzelne Methoden bieten nicht notwendigerweise die Granularität, die ich zum Testen benötige, obwohl eine Reihe von Methodenaufrufen dies tun. Daher ist die Funktionalität, die ich als "Einheit" betrachte, etwas größer als eine einzelne Methode.

    
bedwyr 04.03.2009 03:22
quelle
0

Sie sollten zumindest das Zeug umgestalten, das aussieht, als ob es ein Problem und ein Einheitstest sein könnte. Aber in der Regel sollte eine Funktion nicht so lange sein. Wenn Sie mit dem Refactoring beginnen, finden Sie möglicherweise etwas, das als Einheitstest geeignet ist.

Artikel zum Thema guter Objekt-Mentor auf TDD

    
Ovi Tisler 04.03.2009 03:16
quelle
0

Wie einige wenige zuvor beantwortet haben, gibt es ein paar Möglichkeiten, wie Sie testen können, was Sie beschrieben haben. Zuerst die Formulareingabe, kann auf verschiedene Arten getestet werden. Was passiert, wenn ungültige Daten eingegeben werden, gültige Daten usw. Dann kann jede der Funktionen getestet werden, um zu sehen, ob die Funktionen, wenn sie mit verschiedenen Formen korrekter und inkorrekter Daten geliefert werden, in der richtigen Weise reagieren. Als Nächstes können Sie die Anwendung, die aufgerufen wird, überspie- len, damit Sie sicherstellen können, dass Ihre Anwendung Daten korrekt an die externen Programme sendet und verarbeitet. Stellen Sie nicht sicher, dass Ihr Programm auch mit unerwarteten Daten aus dem externen Programm fertig wird.

Normalerweise muss ich herausfinden, wie ich Tests für ein Programm schreiben möchte, das ich verwalten soll, um zu sehen, was ich manuell tue, um das Programm zu testen. Versuchen Sie dann herauszufinden, wie Sie so viel wie möglich automatisieren können. Beschränken Sie Ihre Testwerkzeuge nicht auf die Programmiersprache, in die Sie den Code schreiben.

    
gdey 04.03.2009 03:52
quelle
0

Ich denke, dass sich eine Welle der Testparanoia ausbreitet :) Es ist gut, die Dinge zu untersuchen, um zu sehen, ob Tests Sinn ergeben, manchmal wird die Antwort nein sein.

Das Einzige, was ich testen würde, ist sicherzustellen, dass falsch eingegebene Formulare korrekt behandelt werden. Ich sehe wirklich nicht, wo sonst ein automatischer Test helfen würde. Ich denke, Sie möchten, dass der Test nicht invasiv ist (d. H. Während des Tests wird keine Aufzeichnung gespeichert), so dass die anderen Möglichkeiten möglicherweise ausgeschlossen sind.

    
Tim Post 04.03.2009 04:00
quelle
0

Wenn Sie etwas nicht testen können, wie wissen Sie, dass es funktioniert? Ein Schlüssel zum Softwaredesign ist, dass der Code testbar sein sollte. Das kann das eigentliche Schreiben der Software erschweren, lohnt sich aber später bei der späteren Wartung.

    
lilburne 04.03.2009 10:31
quelle

Tags und Links