C++ Unit Testing Framework [geschlossen]

Ich würde gerne hören, was ein empfohlenes C++ Unit Testing Framework ist oder, falls es kein einziges gibt, was ein allgemein akzeptiertes Flussdiagramm ist, das mir bei der Auswahl eines helfen kann.

Antworten (2)

Vergleichskriterien für das Unit-Testing-Framework

Sie sollten die folgenden wichtigen Kriterien für den Vergleich von C++ Unit Testing Frameworks berücksichtigen:

  1. Kompatibilität : ob das Framework mit Ihrem Projekt kompiliert wird. Möglicherweise verwenden Sie Optionen wie -fno-rttiund einige Frameworks können dann nicht kompiliert werden.
  2. Benutzerfreundlichkeit : wie viel Arbeit ist es, einen Test zu schreiben. C++ hat keine Reflektion, daher müssen Frameworks die Testregistrierung irgendwie lösen.
  3. Eigenschaften : Kann es das tun, was Sie brauchen? Laut einem Beitrag im Google Testing Blog verfügen die meisten Frameworks über die notwendigen Features und unterscheiden sich meist in den Punkten 1 und 2.
  4. Popularität & Vertrautheit : ob die Leute den Rahmen kennen. Dies ist besonders für freie Software wichtig, um die potenzielle Mitwirkendenbasis nicht einzuschränken.

Beliebte Frameworks und ihre Popularitätsmaße

Um die Popularität zu messen, könnte es ausreichen, Stack Overflow und GitHub zu durchsuchen . Die folgenden Statistiken wurden im Januar 2016 erhoben und können sich im Laufe der Zeit drastisch ändern; auch Trends, die hier nicht dargestellt werden, können wichtiger sein als absolute Zahlen.

Stackoverflow-beliebte Frameworks

Eine Suche nach [unit-testing] [c++] findet 1.211 Fragen zu SO. Auf der Suche nach individuellen Frameworks finden wir:

  • Google Test : 857 Fragen (Schlüsselwort [googletest])
  • CppUnit : 203 Fragen (Stichwortbegriff [cppunit])
  • Fang : 12 Fragen (Stichwortbegriff [catch-unit-test])

GitHub-beliebte Frameworks

Auf GitHub gibt es etwa 461.000 Repositories für die Abfrage „Sprache:C++“.

GitHub:

  • Google Test : 1.870.016 C++ Dateien (Suchbegriff: "include gtest.h")
  • CppUnit : 297.525 C++-Dateien (Suchbegriff: "include cppunit")
  • Fang : 11.888 C++-Dateien (Suchbegriff: "include catch.hpp"(
  • CppUnitLite : 1.214 C++-Dateien (Suchbegriff: "include CppUnitLite")

(die Zahl in „Wir haben xxx Code-Ergebnisse gefunden“, nachdem Sie im linken Menü auf C++ geklickt haben)


Es scheint, dass Google Test ein klarer Gewinner des SO+GitHub-Beliebtheitswettbewerbs ist, höchstwahrscheinlich, weil es von großen Projekten wie LLVM und Chromium übernommen wurde.

Gibt es irgendwo einen Vergleich ihrer Vorzüge? Ihre Feature-Sets?
@einpoklum Meine These ist, dass sie alle ziemlich gleich sind, also sollten Sie sich für die beliebtesten oder diejenigen mit dem größten "Schwung" entscheiden. In Bezug auf Funktionsvergleiche kenne ich diese viel zitierten (älteren) Blogs gamesfromwithin.com/… , accu.org/index.php/journals/1326 und Wikipedia en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B

Ich möchte die Community-Wiki-Antwort um ein paar weitere Punkte ergänzen, die Sie bei der Auswahl Ihres Test-Frameworks berücksichtigen sollten. Dies betrifft Ihre Auswahl eines Test-Tools:

  1. Kostenfreie oder preisgünstige Test-Frameworks wie Google Test und CppUnit werden fast immer beliebter sein, aber Ihre anderen Anforderungen möglicherweise nicht erfüllen .
  2. Erforderliche Testabdeckung:
    1. Wenn Sie einen Benutzercode für ein einfaches kostenloses Softwareprojekt (obwohl viele davon tatsächlich viel bessere Tests haben als kommerzielle Projekte) oder ein Spiel testen, dann sind Sie der Kurve voraus, wenn Sie Komponententests durchführen.
    2. Wenn Sie Code für eine Finanzanwendung oder ein Telekommunikationssystem schreiben, müssen Sie wahrscheinlich 100 % Codezeilen abdecken, dh jede Zeile Ihres Codes sollte während Ihres Tests mindestens einmal ausgeführt werden.
    3. Wenn Sie eine Weltraum-, Militär-, Medizin- oder Luftfahrtanwendung mit geringer Kritikalität schreiben, müssen Sie eine 100-prozentige Linienabdeckung und eine 100-prozentige Entscheidungsabdeckung durchführen – dh jede Linie wird ausgeführt und jede Art, einen Entscheidungspunkt zu durchlaufen, wird ausgeübt.
    4. Wenn Sie sicherheitskritischen Code in einem der oben genannten Bereiche schreiben, müssen Sie 100 % Code- und 100 % Entscheidungsabdeckung auf Op-Code-Ebene durchführen, nicht nur Zeilenabdeckung.
  3. Jegliche erforderliche Zertifizierung Ihres Testwerkzeugs oder Standards, gegen die es getestet werden muss – es ist in der Embedded-Software-Industrie nicht ungewöhnlich, MISRA - Konformität zu verlangen, aber es gibt andere Standards, die in einigen Fällen erforderlich sind.
  4. Die typische Zeit, die benötigt wird, um jeden Testfall zu erstellen – dies kann sich zwischen den Tools enorm unterscheiden und hat einen großen Einfluss auf die indirekten Kosten.
  5. Ob das Testtool für Ihre Bereitstellungsplattform und Toolkette verfügbar ist, sowie Zeit und Kosten für die Einrichtung.
  6. Ob das Tool erfordert, dass Sie Ihren Code in irgendeiner Weise ändern, um die Tests auszuführen – in einigen der oben genannten Branchen müssen Sie Tests mit nicht modifiziertem Quellcode durchführen.
  7. Die Eignung zur Automatisierung des Testens – wenn Sie planen, kontinuierliche Integration auszuführen oder extreme/agile Praktiken anzuwenden, dann ist die Möglichkeit, Ihre Tests und Testberichte zu automatisieren, ein großer Vorteil.
  8. Langlebigkeit – Wenn Ihr Projekt jahrelang läuft oder Ihr Produkt jahrelang unterstützt wird, dann ist der Verlust Ihres Testwerkzeugs eine Katastrophe.
  9. Die Fähigkeit zur Versionskontrolle Ihrer Testskripte ist von entscheidender Bedeutung.
  10. Dasselbe gilt für die Testberichte/Ergebnisse – Sie müssen auch die Möglichkeit haben, Ihre Testergebnisse in einem Format zu veröffentlichen, in dem sie ohne eine Kopie des Testtools zugänglich sind.
  11. Außerdem müssen Ihre Tests und Ergebnisse sowohl zu den Anforderungen als auch zum Quellcode nachvollziehbar sein.

Wenn Sie Komponententests für eingebettete, sicherheitskritische Software durchführen, gibt es nur sehr wenige Tools mit der erforderlichen Unterstützung von Standards und Zertifizierungen. Rational Test RealTime & LDRA Testbed sind Beispiele - aber sie sind nicht billig, da sie für jede Lizenz pro Jahr und Entwickler Zehntausende von Dollar kosten .

Haftungsausschluss - Ich arbeite für keines der oben genannten Unternehmen, habe aber ihre Produkte verwendet, da ich intensiv in der sicherheitskritischen, eingebetteten Echtzeitbranche gearbeitet habe.