Unit-Tests nicht exportierte Klassen in einer DLL

Entwickeln wir eine C++ - Anwendung mithilfe von Visual Studio 2008 und unit-test mit Boost.Test. Im moment haben wir eine separate Lösung, die enthält unsere unit-tests.

Viele unserer Projekte in die core-Lösung produzieren DLL. Wir sind begrenzte Testabdeckung, weil wir Sie nicht testen, nicht exportierte Klassen.

Ich habe zwei Ideen, wie diese getestet werden konnte:

Export alles
Setzen Sie die tests in der DLL (gleiche Projekt und Lösung) und die Verwendung von Boost.Test externe Läufer

Ich bin mir nicht ganz sicher, was die Nachteile sein würde. Nummer 1 oben Pausen von Modul-level-Kapselung, und die Nummer 2 könnte in eine viel größere DLL, es sei denn, es ist möglich, um nur den test-code in bestimmten Konfigurationen.

So, gibt es irgendwelche gravierenden Nachteile zu den oben genannten Methoden, oder können Sie sich andere Lösungen überlegen?

Ich würde gerne der Hinweis auf CMake bietet eine Funktion namens "Objekt-Bibliotheken". (add_library( foo_obj OBJECT ... )) In meinen Projekten Baue ich die Quellen in Objekt-Bibliotheken, die ich dann den link in die DLL (add_library( foo SHARED ... $<TARGET_OBJECTS:foo_obj> )) und seine test-Treiber (add_executable( foo_test ... $<TARGET_OBJECTS:foo_obj> )). Es ist eine Variante von den Antworten, die unten mit einem anderen build-system (das ist, warum ich fügte hinzu, diese als Kommentar, keine Antwort), aber es ist die Lösung des gleichen Problems.

InformationsquelleAutor Jon | 2011-03-31

boost-test c++unit-testing visual-studio

15

Erweiterung auf Tom Quarendon Antwort auf diese Frage, ich habe eine leichte Variante von Simon Steele Antwort:
- Erstellen Sie ein test-Projekt (mit was auch immer test-framework, die Sie mögen, ich benutze CppUnit).
- In Ihrem test_case.cpp, #include <header/in/source/project.h>.
- In der test-Projekt-Eigenschaften:
  - Im Linker->allgemein, fügen Sie die source-Projekts $(IntDir) um die Zusätzliche Bibliothek-Verzeichnisse.
  - Im Linker->Eingabe, fügen Sie die .obj - Dateien, um die Zusätzlichen Abhängigkeiten.
- Die Abhängigkeit von dem test-Projekt mit der source-Projekt im Projekt->Projekt-Abhängigkeiten.
Wieder, der einzige Wartungsaufwand ist der standard für unit-tests zu erstellen, die die Abhängigkeit der Einheit(en), die Sie testen möchten.
- Weitere Details zu diesem Ansatz: Wenn die DLL unter test verwendet pre-compiled Header, alle .obj-Dateien, die verknüpft sind, erzeugen Sie die DLL unter test hängt von der vorkompilierten header-Datei aus der DLL im test. Bei der Erstellung des Test-Projekt, dies führt zu linker-Fehler LNK2011: vorkompilierte Objekt nicht verknüpft; Bild kann nicht ausgeführt werden. Neben der konkreten Objekt-Dateien, die Sie testen, müssen Sie stdafx.obj (wenn Ihre PCH-Datei wird generiert durch das kompilieren stdafx.cpp).
- Ein weiterer Hinweis auf diesen Ansatz: Wenn dein test-Projekt mit mehreren dlls, die den gleichen Namen Objekt-Dateien, die geprüft werden müssen, können Sie geben Sie den vollständigen Pfad in der Linker->Eingabe-Einstellungen, z.B. $(SolutionDir)\<project_name>t\$(Platform)\$(Configuration)\<object_name>.obj zwischen Ihnen zu unterscheiden.
- Möglicherweise müssen Sie auch /FORCE:MULTIPLE, wie ich gerade entdeckt.
- Um zu vermeiden, geben Sie alle Dateinamen aus, kann man stattdessen tun Sie es in der Befehlszeile zusätzliche Optionen über eine wildcard, wie in stackoverflow.com/a/25776187/640195
- Warum sollte ich das obj nicht in der lib? was sind die Unterschiede? weil es funktioniert nur mit .obj, nicht mit .lib
InformationsquelleAutor Rai
4

Die Lösung, die ich für das ist zu bauen, die die gleichen nicht-exportierten code in meine tests-DLL. Diesen nicht zu erhöhen, bauen Zeit und bedeutet alles hinzuzufügen, um beide Projekte, sondern spart auch exportieren alles oder setzen Sie die tests in der Haupt-Produkt-code.

Andere Möglichkeit wäre zum kompilieren des nicht-exportierten code in eine lib, die verwendet wird, die mit DLL-Exporten und der unit-test-Projekt.
- Dies könnte arbeiten für kleine Projekte, aber wir haben eine Menge code, so wäre es ein Albtraum Wartung zu haben, um änderungen an zwei stellen.
- Die einzigen änderungen, dass würde müssen gemacht werden, obwohl, wenn Dateien Hinzugefügt oder entfernt werden. Wenn also eine neue CPP-Datei Hinzugefügt wird, enthält code, der muss sein Gerät getestet, dann muss es Hinzugefügt werden, dass beide Projekte. Es gibt nicht zwei Kopien des Quellcodes, jede source-Datei mit testbarem code ist nur bei beiden Projekten berücksichtigt.
- Dies war mein Erster Ansatz, die für mich gearbeitet hat. Ich dachte, dass ein potentielles problem mit ihm, obwohl - manchmal ist ein dll-Projekt verwendet verschiedene compile-flags als das test-Projekt. Also, die dll und testen Sie Projekte erstellen, die verschiedene Objekt-Dateien für die gleiche Quell-Datei. Obwohl in meinem Fall war ich mir ziemlich sicher, Sie waren die gleichen, im Allgemeinen ist es sicherer, testen Sie die Objekt-Dateien, die das dll-Projekt erstellt, anstatt die Objekt-Dateien, die das test-Projekt erstellt. Landete ich Wechsel mein Ansatz zu der ein @Rai beschrieben.
InformationsquelleAutor Simon Steele
2

War auf der Suche einer Lösung, vielleicht sind die folgenden leichter zu pflegen.

Fügen Sie eine neue build-Konfiguration, z.B. "Unit-testing, Debug", um die DLL-Projekt, und ändern Sie die Konfiguration Typ "Static Library .lib" ("allgemein"->"Konfiguration").

Dann fügen Sie einfach eine Abhängigkeit von Ihrer unit-tests auf dieses Projekt, jetzt sollte alles miteinander verknüpfen, wenn Sie neue build-Konfiguration "Unit-testing, Debug".
Wenn Sie mit release-builds für unit-tests, dann müssen Sie eine andere Konfiguration mit dem release Optimierungen.

So die Vorteile dieser Lösung sind:
- niedrigen maintanability Kosten
- einzigen DLL/Static library-Projekt
- nicht manuell verknüpfen .obj-Dateien
Nachteile:
- Zusätzliche Konfigurations-Profil(s) erfordert einige änderungen in Ihrer build-Umgebung (CI)
- Größere Zusammenstellung mal
Update:
Wir tatsächlich am Ende mit einem anderen Ansatz.

Wir neue "Test-debug"/"Test-release' - Konfigurationen für jedes vorhandene Projekt, das wir haben.

Für .exe/.dll Projekte, die wir deaktivieren das original main.cpp kompilieren und ersetzt es mit dem, instanziiert der test-Frameworks (z.B. gtest) und führt alle tests, die tests werden in separaten .cpp-Dateien, die ausgeschlossen sind auch aus der Zusammenstellung in der regulären Konfiguration (Release/Debug) und aktiviert nur im-Test-Konfigurationen.

Für .lib-Projekte wir haben auch neue "Test-debug"/"Test-release" - Konfiguration und wir konvertieren Sie die statische Bibliothek ein .exe-Datei und stellen Sie ein main.cpp die instanziiert der Test-Frameworks und führt die tests und die tests selbst. Testen Sie die zugehörigen Dateien werden ausgeschlossen aus der Zusammenstellung auf Release/Debug-Konfigurationen.

InformationsquelleAutor AndreiM
0

Versuchen Sie es mit einer Definition wie der folgenden, die irgendwo alle Dateien enthalten:
```
#define EXPORTTESTING __declspec(dllexport)
```
Und verwenden Sie es anstelle des dllexport, wie diese:
```
class EXPORTTESTING Foo 
{
 ...
};
```
Dann werden Sie in der Lage sein zu deaktivieren das flag für den Aufbau einer release DLL, aber halten es für eine unit-testbar DLL.
- Nicht sicher, es ist eine gute Weise zu tun, wie die... Die testbaren code sollte nicht geändert werden, getestet werden. Auch wenn es ein einfaches makro.
InformationsquelleAutor Janik Zikovsky

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.