Wie testet man eine EXE mit Google Test?

Nach Ihren Kommentaren haben Sie eine C ++ - Konsolenanwendung ( MyApp) , für die Sie einige anwendungsspezifische Klassen entwickelt haben, die Sie mit googletest in Unit testen möchten Visual Studio Wie?

Wie Sie sagen, wenn Sie Unit-Test eine Bibliothek möchten, wäre die Art und Weise es zu tun offensichtlich. Du würdest:

• 1) Erstellen Sie ein Projekt zum Erstellen einer Unit-Test-Anwendung ( UnitTest ).
• 2) Konfigurieren Sie die include-search-Verzeichnisse, damit der Compiler die Header der Bibliothek finden kann.
• 3) Konfigurieren Sie die Bibliothekssuchverzeichnisse so, dass der Linker die Bibliothek selbst finden kann.
• 4) Fügen Sie die Bibliothek selbst den Linker-Eingaben hinzu.
• 5) Machen Sie das UnitTest -Projekt abhängig vom Bibliotheksprojekt, so dass das Erstellen von UnitTest sicherstellt, dass MyApp auf dem neuesten Stand ist.
• 6) Codieren Sie die UnitTest App pro Google-Testdokument.

Aber da die Klassen, die Sie testen wollen, spezifisch für MyApp sind, haben Sie keine Bibliothek.

Eine Antwort darauf lautet: Sie haben keine Bibliothek mit den Klassen, die Sie testen möchten? Also mach einen!

Auf diese Weise verwenden Sie 3 Projekte: -

• MyAppLib , erstellt eine Bibliothek mit allen Funktionen, die Sie testen möchten.
• MyApp , erzeugt dieselbe ausführbare Datei wie zur Zeit, aber verknüpft MyAppLib
• UnitTest , generiert eine ausführbare Datei, die Unit-Tests MyAppLib , auch die Verknüpfung MyAppLib

Wenn Sie jedoch die Antwort des Drill-Sergeants nicht mögen, können Sie damit umgehen.

Aus der üblichen Sicht des Build-Systems (die in Visual Studio entworfen wurde) Die wichtige Ausgabe des Projekts MyApp ist das Build-Ziel - .exe . Die erzeugten .obj Dateien sind nur Zwischenprodukte. VS bietet Ihnen keine Unterstützung um diese Nebenprodukte als automatische Linker-Eingaben eines abhängigen Projekts zu behandeln, und wenn ein abhängiges Projekt auch ein .exe der gleichen Art war - wie es in Ihrem Fall der Fall ist - wäre eine solche automatische Verknüpfung sowieso wegen des Haupteinstiegs unmöglich wäre mehrfach definiert.

Aber vom Standpunkt des Unit-Testing ist es umgekehrt. Das .exe ist nicht von Interesse, wohingegen (teilweise) die .obj -Dateien die Implementierungen der Klassen, die Sie testen wollen, ganz oder teilweise enthalten. Im Fall eines Lehrbuchs, in dem die Klasse foo in foo.h definiert und in foo.cpp implementiert ist, wird die Objektdatei foo.obj in der Verknüpfung von UnitTest benötigt.

Der Einfachheit halber wird angenommen, dass MyApp nur eine anwendungsspezifische Klasse foo verwendet. definiert in foo.h und implementiert in foo.cpp . Dann haben Sie zwei Optionen zum Erstellen von UnitTest .

• a) Sie können foo.cpp zu den Quelldateien von UnitTest hinzufügen. kopiere es natürlich nicht. Nur Fügen Sie ein vorhandenes Element aus dem Quellordner von MyApp hinzu. Dann bist du fertig, aber das Natürlich hat der Nachteil, dass foo.cpp einer unerwünschten Bearbeitung ausgesetzt ist das Projekt UnitTest .

• b) Sie können foo.obj genau wie eine statische Bibliothek behandeln, die für die Verknüpfung von UnitTest benötigt wird, und die obigen Schritte 1) - 6) befolgen. Dies bedeutet insbesondere in Schritt 3), dass das {Debug | Release} -Build von UnitTest mit Verzeichnissen für die Bibliothekssuche konfiguriert wird, die \path\to\MyApp\{Debug|Release} (entweder in relativer oder absoluter Form) enthalten.

In Wirklichkeit gibt es für Option b) sehr wahrscheinlich mehr als eine .obj -Datei von MyApp , die Sie in UnitTest verknüpfen müssen, und ziemlich wahrscheinlich, dass ihre Anzahl mit der Zeit wächst. Das Aufrechterhalten der richtigen Verbindung von UnitTest könnte zu einer lästigen Pflicht werden, und Sie könnten zu dem Schluss kommen, dass der Drill-Sergeant doch recht hatte.

Hängt davon ab. Google Test ist (hauptsächlich) ein Unit-Testing-Framework (zu stark vereinfachende, getestete Klassen). Sie können absolut für andere Arten von Tests verwenden, aber es hat keine "eingebaute" Funktionalität für andere Arten von Tests, Sie müssen es selbst schreiben.

Wenn Sie versuchen, Ihre ausführbare Datei zu testen, können Sie den Prozess ausführen. Ich empfehle Boost.Process, wenn Sie ein Multi-Plattform-System verwenden oder bereits eine Boost-Abhängigkeit haben. Sonst schaue hier: starte einen exe / process mit stdin stdout und stderr?

Die von Ihnen geschriebenen "Tests" rufen die ausführbare Datei auf und können entsprechend stdin oder stdout eingeben.

Zum Beispiel:

Ich befand mich in einer ähnlichen Situation, und ich habe dies so eingerichtet, dass das Ziel von Mike Kinghans Antwort für den Compiler tatsächlich erreicht wird, aber es geht anders als in der Perspektive des Benutzers.

Ich habe eine benutzerdefinierte Konfiguration erstellt, die ich "Testing" nannte. Sie erstellen eine neue Konfiguration, indem Sie die Projekteinstellungen öffnen, "Konfigurationsmanager ..." wählen und im Konfigurationsauswahlfeld "Neu ..." auswählen.

Wenn ich dazu aufgefordert wurde, habe ich die Einstellungen aus der Standardkonfiguration "Debug" kopiert, damit ich den Debugger mit meinen Tests genauso verwenden kann wie in der "Debug" -Konfiguration.

Unter der neuen Testing-Konfiguration habe ich die Optionen für den Compiler und den Linker festgelegt, um google test wie gewohnt zu verwenden.

Die wichtige Änderung in den Eigenschaften ist, dass ich eine Präprozessorvariable definiere, die ich "TESTING" genannt habe.

Ich habe meine "main.cpp" so umgeschrieben, dass sie so aussieht:

Was ich anzudeuten versuche ist, dass ich nur ein paar Zeilen genau dort geändert habe, wo main definiert ist. Ich muss keine groben Änderungen in der Datei vornehmen.

Nun, da dies alles eingerichtet ist, habe ich einfach einen neuen Quellordner für meine Tests erstellt und dort ".cpp" -Dateien erstellt. Um das Aufblähen der normalen ausführbaren Datei zu vermeiden, verpacke ich diese Dateien mit einer Überprüfung für die Variable TESTING, also habe ich etwas wie folgt:

tests/Test.cpp:

Ich denke, diese Dateien werden vom Compiler unter Debug- und Release-Konfigurationen immer noch "getroffen", so dass eine Menge davon den Build verlangsamen kann, aber die Debug- und Release-Objekte werden nicht mit Testcode aufgebläht.

Die zwei Takeaways sind:

• Bei Verwendung dieser Methode ist der Testcode weiterhin getrennt vom Anwendungscode organisiert, befindet sich jedoch immer noch im selben Visual Studio-Projekt, was möglicherweise von Vorteil ist. Persönlich mag ich es nicht, dass ich mich um ein zweites Projekt kümmern muss.
• Wie Mike Kinghan schon sagte, kann die Verwaltung und Verknüpfung von .obj -Dateien selbst zu einer lästigen Pflicht werden, aber bei Verwendung dieser Methode verwalten die Standard-Visual Studio-Einstellungen dies für Sie.

Ein Nachteil ist, dass effektiv redundante Kopien aller Objektdateien im Ausgabeverzeichnis "Testing" erstellt werden. Mit mehr Konfiguration, sicherlich muss es eine Möglichkeit geben, die Debug-Objekt-Dateien zu "teilen", aber ich hatte keinen Grund, so weit zu gehen.

Dies ist eine sehr einfache Methode, die sehr viel einfacher ist als das Refactoring Ihrer Anwendung in separate Bibliotheken und ein Hauptprogramm. Ich liebe nicht mit Präprozessor Wankery, aber in diesem Fall ist es ziemlich einfach, nicht zu viel Code aufgebläht und erreicht genau das, was es braucht. Sie könnten die Tests immer auf andere Weise auslösen, ohne den Präprozessor zu verwenden.

Wenn Sie eine Konsolenanwendung testen möchten, können Sie einen Test ausführen, der ein Konsolenfenster öffnet und die EXE-Datei der ersten App ausführen. Dann in Ihrem googletest fangen Sie die Standardausgabe von der exe ab, die Sie gerade laufen ließen.

[Für mehr Kontrolle über die erste App müssen Sie möglicherweise die ersten App-Analyseargumente erhalten, z. einige Flaggen wie -x oder was immer du brauchst.]

Ich habe ein Github Repo vorbereitet, das die Visual Studio 2015 Lösung enthält, und zwar in Übereinstimmung mit Mikes "Drill-Sergeant" Vorschlag. Sie können es direkt ohne zusätzliche Anforderung oder Abhängigkeit verwenden.

Ссылка

Ich hoffe, es hilft ...

Wenn Sie die Tests nicht in einem anderen Projekt durchführen möchten, können Sie die Tests in Ihr Anwendungsprojekt schreiben. Führen Sie dann die Anwendung nur aus, wenn sie bestimmte Befehlszeilenargumente empfängt, und führen Sie andernfalls die normale Anwendungslogik aus, d. H.

Dadurch wird vermieden, dass eine unnötige Bibliothek zum alleinigen Zweck des Testens erstellt wird, obwohl Sie es immer noch tun können, wenn es strukturell korrekt ist. Der Nachteil ist, dass der Testcode in die ausführbare Datei eingeht, die Sie veröffentlichen werden. Wenn Sie das nicht wollen, brauchen Sie vermutlich eine zusätzliche Konfiguration, die eine Pre-Prozessor-Direktive vorgibt, um die Tests zu deaktivieren.

Das Debuggen der Tests oder das automatische Ausführen dieser Tests beim Post-Build ist einfach, indem Sie einfach "--tests" als Debug-Argumente oder bei der Post-Build-Befehlszeile angeben.