C++ Code Tests

Hallo Leute,

ich wollte mein Projekt, mit Tests absichern bzw. überprüfen lassen. Ich habe es unter eclipse Programmiert.

Gibt es Tools bzw. Frameworks, die C++ Codes überprüfen?

Ich hatte von Boost Test, Google Testing Framework, CppUnit, CUTE - C++ Unit Testing Easier usw. gelesen.

Was ist eigl. Stand der dinge beim C++ Testen? Was ist eigl das beste Framework für Unittests?

Viele Grüße
Tron36

http://stackoverflow.com/questions/242926/comparison-of-c-unit-test-frameworks

Ich nutze auf der Arbeit und privat GoogleTest und ich würde es weiter empfehlen.
Hier ist ne sehr einfache Anleitung für Linux bzw *buntu:
* Install GTest:
sudo apt-get install libgtest-dev
sudo apt-get install cmake
cd /usr/src/gtest
sudo cmake CMakeLists.txt
sudo make
* copy or symlink libgtest.a and libgtest_main.a to your /usr/lib folder
sudo cp *.a /usr/lib

Einfach Bibliotheken in /usr reinkopieren. Was kann da schon schiefgehen?
Wenn schon, dann nimm doch bitte wenigstens /usr/local. Und hat das etwa kein installtarget im Makefile?

Kann auch GoogleTest empfehlen.

Unit Tests: https://msdn.microsoft.com/en-us/library/dd264975.aspx

Kann mich nicht beklagen

Meiner Meinung nach sind Unit Tests meistens reine Zeitverschwendung. Die Art von simplen Szenarios in völliger Isolation vom Rest des Systems, die Unit Tests abdecken, sind genau die, die in der Realität so gut wie nie Probleme verursachen.

Und kriegt man es tatsächlich hin, einen so umfangreichen Unit Test zu entwickeln, dass der wirklich einen erheblichen Teil der möglichen Szenarien abdeckt, wird das schnell dermaßen komplex, dass man eigentlich als nächstes einen Test für den Test schreiben müßte.

Ich bin hier auch Teilweise bei antred: Man sollte nicht nur die "unterste Ebene" von allen Klassen/Methoden Testen sondern versuchen auf höherer Ebene weil der Aufwand sonst zu groß wird.
Man kann aber natürlich auch mit UnitTests auf höherer Ebene arbeiten. zB könnte eine Klasse "Filter" mit verschiedenen Modi arbeiten und jeweils mit Eingabedaten gefüttert werden für die dann geprüft wird, ob jedes mal der erwartete Ausgabewert erscheint. Dadurch wird quasi indirekt auch der zugrundeliegende (und evtl sehr große) Mathe-Teil mit geprüft, weil dass trotz neuerdings gemachter Fehler hierdrin immernoch für alle Fälle exakt das selbe errechnet wird ist quasi unmöglich.

Ums kurz zu machen: C++ programs are untestable

Gruß
Andy

Man sollte nicht nur die "unterste Ebene" von allen Klassen/Methoden Testen sondern versuchen auf höherer Ebene weil der Aufwand sonst zu groß wird.

Zum Vergrößern anklicken....

Doch eher umgekehrt. Bei einer einzelnen Thread-Klasse kann ich testen, ob sie einen Thread korrekt erstellt und ausführt, aber wie zum Henker soll ich ein Thread Pool-System mit mehreren Workern testen, wenn ich noch nicht einmal von außen beeinflussen kann, wie genau der Code abgearbeitet wird?

antred hat schon irgendwo recht. Unittests haben ihre Daseinsberechtigung für Implementierungen von Standardbibliotheken o.ä. (oder wenn man sowas einfach selbst macht, weil man die STL hasst... hust hust), sie können sinnvoll sein, wenn man eine Funktion optimiert, aber bei komplexeren Systemen müsste man a) schon wissen, wo potentielle Fehler liegen, b) in der Lage sein, das System bis ins kleinste Detail zu beeinflussen und c) würde man wahrscheinlich extrem implementierungsspezifisch testen, was den Test bei Veränderung der Implementierung obsolet macht.

An der Uni mussten wir sowas bei einem Java-Projekt auch mal machen. Ein Kartenspiel. Lief dann darauf hinaus, dass man irgendwie mal jede Funktion aufgerufen und eine Alibi-Assertion eingebaut hat, damit das JUnit-Ding von Eclipse 100% Code-Coverage anzeigt, aber wirklich getestet wurde da außer einigen Basisklassen rein gar nichts.

antred schrieb:

Meiner Meinung nach sind Unit Tests meistens reine Zeitverschwendung. Die Art von simplen Szenarios in völliger Isolation vom Rest des Systems, die Unit Tests abdecken, sind genau die, die in der Realität so gut wie nie Probleme verursachen.

Zum Vergrößern anklicken....

Deshalb a) testet man mit Äquivalenzklassen, um alle Szenarien abzudecken und b) hat man nicht umsonst Unit- und Integrationstests.

"Reine Zeitverschwendung", "Alibi-Assertion" und was man hier alles lesen muss klingt leicht stümperhaft, aber no offense. Wenn es sich schlecht testen lässt, liegt das übrigens oftmals am Code selbst.