Wie führen Sie Ihre Komponententests durch? Compiler-Flags? Statische Bibliotheken?

Question

Ich beginne gerade mit TDD und bin neugierig, was andere angehen, um ihre Tests durchzuführen. Als Referenz verwende ich das Google-Test-Framework, aber ich glaube, dass die Frage auf die meisten anderen Test-Frameworks und auf andere Sprachen als C/C++ anwendbar ist.

Mein allgemeiner Ansatz ist bisher eines der drei Dinge zu tun:

1. die Mehrheit der Anwendung in einer statischen Bibliothek schreiben, dann zwei ausführbare Dateien erstellen. Eine ausführbare Datei ist die Anwendung selbst, die andere ist der Test-Runner mit allen Tests. Beide verbinden sich mit der statischen Bibliothek.

2. Betten Sie den Testcode direkt in die Anwendung ein und aktivieren oder deaktivieren Sie den Testcode mithilfe von Compilerflags. Dies ist wahrscheinlich der beste Ansatz, den ich bisher verwendet habe, aber den Code etwas auffrischen.

3. Betten Sie den Testcode direkt in die Anwendung ein, und führen Sie bei bestimmten Befehlszeilenschaltern entweder die Anwendung selbst aus oder führen Sie die in die Anwendung eingebetteten Tests aus.

Keine dieser Lösungen sind besonders elegant ...

Wie Sie es tun?

Answer 1

Ich bevorzuge statische libs über dlls, so dass die meisten meiner C++ - Code in statischen Bibliotheken sowieso landen und wie Sie gefunden haben, sind sie so einfach zu testen wie dlls.

Für Code, der in eine Exe eingebaut wird, habe ich entweder ein separates Testprojekt, das einfach die zu testenden Quelldateien enthält und die normalerweise in die EXE eingebaut sind ODER ich baue eine neue statische lib, die die meisten exe und enthält teste das auf die gleiche Weise, wie ich alle meine anderen statischen Bibliotheken teste. Ich finde, dass ich den Ansatz der "meisten Code in einer Bibliothek" in der Regel mit neuen Projekten und dem "ziehe die Quelldateien aus dem Exe-Projekt in den Test-Projekt" -Ansatz, wenn ich Tests in bestehende Anwendungen nachrüsten.

Ich mag Ihre Optionen 2 und 3 überhaupt nicht. Verwalten der Build-Konfigurationen für 2 ist wahrscheinlich schwieriger als mit einem separaten Test-Projekt, das einfach die Quellen zieht und alle Tests in die exe, wie Sie in 3 vorschlagen, ist einfach falsch;)

Answer 2

Ich verwende einen Test-Läufer von Drittanbietern mit ihrem Framework und Tests in Build-Skript enthalten. Tests sind außerhalb des Produktionscodes (externe DLL).

Answer 3

Ihr Ansatz Nr. Ich habe es immer in C/C++ und Java gemacht. Der Großteil des Anwendungscodes befindet sich in der statischen Bibliothek, und ich versuche, den für die Anwendung erforderlichen zusätzlichen Code auf ein Minimum zu beschränken.

Die Art, wie ich TDD in Python und anderen dynamischen Sprachen anwende, ist etwas anders, da ich den Quellcode für die Anwendung und Tests herumliegen lasse und ein Testläufer die Tests findet und ausführt.

Answer 4

Ich benutze zwei Ansätze, für dlls verbinden ich einfach meine Unit-Tests mit der DLL, einfach. Bei ausführbaren Dateien schließe ich die Quelldateien ein, die sowohl im ausführbaren Projekt als auch im Komponententestprojekt getestet werden. Dies fügt etwas zur Build-Zeit hinzu, bedeutet aber, dass ich die ausführbare Datei nicht in eine statische Lib und eine Hauptfunktion trennen muss.

Ich benutze boost.test für Komponententests und CMake, um meine Projektdateien zu generieren, und ich finde dies den einfachsten Ansatz. Außerdem führe ich langsam Unit-Testing in eine große Legacy-Code-Basis ein, so dass ich versuche, die geringste Menge an Änderungen einzuführen, falls ich andere Entwickler belästige und sie davon abhalte, Unit-Tests durchzuführen. Ich würde mir Sorgen machen, dass die Verwendung einer statischen Bibliothek nur für Unit-Tests als Entschuldigung betrachtet werden könnte, um sie nicht zu übernehmen.

Mit diesen gesagt, ich denke, die statische Bibliothek Ansatz ist eine nette, vor allem, wenn Sie bei Null anfangen.

Answer 5

Für C/C++ - Anwendungen versuche ich, so viel Code wie möglich in einer oder mehreren DLLs zu haben, wobei die Hauptanwendung das absolute Minimum zum Starten und Weiterreichen an die DLL ist. Dlls sind viel einfacher zu testen, da sie so viele Einstiegspunkte exportieren können, wie es für eine Testanwendung ausreicht.

Ich verwende eine separate Testanwendung, die auf die Dll (s) verweist.Ich bin sehr dafür, Testcode und "Produkt" -Code in separaten Modulen zu halten.

Answer 6

Ich gehe mit # 1, einige Gründe sind

• Es ermöglicht zu prüfen, ob die jeweils lib Links korrekt
• Sie wollen nicht, zusätzlichen Code in das Produkt
• Es ist einfacher, einzelne kleine zu debuggen Testprogramme
• Sie können für einige Tests mehrere ausführbare Dateien benötigen (wie Kommunikationstests)

für C++ zu bauen und zu testen, ich gerne mit CMake, das eine Auswahl der ausführbaren Zieldateien als Tests ausführen und eine Zusammenfassung der Ergebnisse ausgeben kann.

Answer 7

Persönlich, ich benutze ein anderer Ansatz, der ein wenig auf Ihrem beruht:

Ich halte das Projekt-to-Test intakt. Wenn es sich um eine ausführbare Datei handelt, sollte sie eine ausführbare Datei bleiben. Sie erstellen einfach eine Post-Build-Aktion, um alle Obj-Dateien in einer statischen Bibliothek zu aggregieren.

Anschließend können Sie Ihr Testprojekt erstellen, indem Sie das Testframework mit Ihrer zuvor erstellten statischen Bibliothek verknüpfen.

Hier sind einige Themen zu Ihrer Frage entsprechen:

• Visual Studio C++: Unit test exe project with google test?
• Linker error - linking two "application" type projects in order to use Google Test