Code-Testing Frameworks: Welches? Erfahrungen etc.

rüdiger

Hallo,
Code-Testing ist ja eigentlich relativ wichtig. Oft sieht man Fehler, die entstehen, wenn man Code erweitert oder ähnliches. Deswegen wollte ich wissen, ob ihr Code-Testing Frameworks benutzt und wenn ja welche und welche Erfahrungen habt ihr so.

Besonders Kommentare von Leuten im professionellem Bereich würden mich interessieren.

Hier mal eine Auswahl
*Boost::Text
*DejaGNU
*Fit (nicht für C++)
...

Jester

Ich hab einmal was mit fit gemacht. Ich fand's zum Kotzen. Macht keinen Spaß das zu schreiben... und manchmal ist der Test nicht gelaufen, obwohl es manuell funktioniert hat. Lag dann an irgendwelchen Kleinigkeiten.

rüdiger

hat sonst niemand so etwas mal genutzt? *push*

@Jester
fit gibt es aber nicht für C++?

Prof84

http://www.xprogramming.com/software.htm
http://www.aptest.com/resources.html

John Doe

http://sourceforge.net/projects/cppunit/
Scheint zumindest für mittelgrosse Projekte brauchbar zu sein.

mfg JJ

TheBigW

Sorry @all, wenn ich jetzt den Beitrag mit 'ner eigenen Frage torpediere:

Mir fehlt zum Thema irgendwie das grundlegenden Verständnis. Wenn ich das richtig verstehe, werden ja bei solchen Tests nur die Funktionen, die ich geschrieben habe von Testing Funktionen aufgerufen. Was bringt mir das dann? Wie schreibt man Code für automated testing?
Es giebt ja auch diverse Tools, die sogar Usereingaben in scripten simuliert generieren. Heißt das, das ich dann mit sowas so teste, das ich das script verschiedene Actionen in verschiedenen Varianten durchlaufen lassen kann und meine Anwendung mir idealerweise Logfiles über ihre Zustände schreibt?

Grund für meine Frage ist die schlechte Testmoral in unserer Firma. Ich glaube das ein Rechenknecht auf alle Fälle besser Testen kann als unsere Tester.

Shade Of Mine

TheBigW schrieb:

Wenn ich das richtig verstehe, werden ja bei solchen Tests nur die Funktionen, die ich geschrieben habe von Testing Funktionen aufgerufen.

Ja.
Natürlich kann ein Test auch komplexer sein und mehrere Funktionen bzw. Tätigkeiten testen

Was bringt mir das dann?

Einmal muss man den Test schreiben, kann ihn aber theoretisch immer wieder verwenden. Denn wer testet gerne eine Funktion die er schon 100mal getestet hat?

Wie schreibt man Code für automated testing?

Man muss irgendwie Eingaben generieren und diese dann validieren können.
zB

int mul(int a, int b) { return a*b; }

hier weiss ich, dass das Ergebnis=a*b ist. Um nun zu testen ob a*b geklappt hat, kann ich testen ob a=Ergebnis/b; ist.

Auf diese Art und weise kann man Testfälle künstlich erzeugen. Das setzt aber voraus, dass man ein Ergebnis validieren kann. Kann man das nicht, sitzt man in der Patsche.

Heißt das, das ich dann mit sowas so teste, das ich das script verschiedene Actionen in verschiedenen Varianten durchlaufen lassen kann und meine Anwendung mir idealerweise Logfiles über ihre Zustände schreibt?

Die Logfiles musst du selber schreiben - aber ja, wenn man automatisiert testet, dann generiert ein Script Szenarien und alles was der Programmierer noch tun muss ist auf "Testen" klicken

Natürlich erst nachdem das Test-Script richtig eingestellt ist - schließlich kann es sonst ja nicht wissen welche Ausgabe richtig ist.

Grund für meine Frage ist die schlechte Testmoral in unserer Firma. Ich glaube das ein Rechenknecht auf alle Fälle besser Testen kann als unsere Tester.

Besser sicher nicht - aber öfter.

Du kennst doch seine Tester gar nicht. Vielleicht sind sie ja wirklich noch schlechter.
Wenn ich mich nicht täusche ist CppUnit eine Portierung der JUnit-Tests für C++. Hört sich also vielversprechend an.

TheBigW

Yop, das hat die meisten Fragen ausgezeichnet beantwortet. Ich checke halt schon relativ viel über asserts ab. Meist habe ich auch eine eingebauten und abschaltbaren Logging Modus.
Eingabevalidierungen werden dann also direkt in den Code integriert. Wo liegt dann der unterschied zu einem normalen assert, mal abgesehen von den kopmplexeren Möglichkeiten von z.B. boost::test.

Daraus, das hier so wenig Antworten kommen schließe ich mal, das diese Vorgehensweise wohl nicht sehr verbreitet ist.

Jester

Mit nem normalen assert prüfst Du zur Laufzeit auf Vorbedingungen. Die Idee eines automatischen (unit-)Tests ist eine andere:

Du läßt den Test laufen und prüfst, ob er sich so verhält, wie Du das erwartest. Zum Beispiel, daß bestimmte Rückgabewerte stimmen oder bei bestimmten Aufrufen die richtige exception fliegt. Dieses testen machst Du _nicht_, indem Du es auf Konsole schreibst oder in ein Log wo Du dann manuell vergleichen mußt, denn das macht keiner. Ist so. Zumindest nicht auf Dauer. Also muß es automatisch passieren. Du kodierst also sowohl die Aufrufe und das Ergebnis, vergleichst die im Test und zählst dann die Anzahl der bestandenen/fehlgeschlagenen Tests hoch. Der Vorteil ist: Du kannst jetzt so oft testen wie Du willst. Es kostet Dich nicht mehr als ein paar Mausklicks. Mit jUnit in Eclipse zum Beispiel einen. Wenn Du jetzt Deine unit mit genügend Testfällen ausgestattet hast und Du etwas änderst, dann kannst Du anhand der Tests relativ gut prüfen, ob Du was kaputt gemacht hast. Eine 100% Garantie kriegste zwar nicht, aber immerhin etwas.
Interessant ist das vor allem bei Bugfixing, da baut man nämlich gerne was neues ein, oder eliminiert alte Bugfixes, weil's "ja auch viel einfacher geht". Deshalb für entdeckte Bugs erstmal nen Testfall baun der diesen bemerkt, danach fixen und wenn jemand zukünftig was ändert und den aus versehen wieder einbaut schlägt der Test fehl.

Wenn man jetzt alle davon überzeugen könnte Code nur in die Versionsverwaltung einzuchecken wenn alle Test laufen... ja dann wäre man ein großes Stück weiter.

MfG Jester

TheBigW

Ahhh Ja, Ich sehe, das ist ein Thema, mit dem ich mich mal eingehender beschäftigen sollte.

Mit nem normalen assert prüfst Du zur Laufzeit auf Vorbedingungen.

Mhh, wortwörtlich nur auf Vorbedingungen? Ich teste damit an allen Stellen (auch Rückgabewerte), wo ein Fehlschlagen richtig weh tut.

Aber ein vernünftiges Testframework für ein Projekt zu schreiben ist ja dann auch schon richtig Arbeit. Da habe ich wohl auch noch eine Menge Überzeugungsarbeit zu leisten. Eigentlich müßte man ja, wenn man es richtig machen will schon ein bisschen Test-orientiert entwickeln. Ich denke gerade mit grausen daran, sowas in ein bestehendes, größeres Projekt zu integrieren.

Danke @all für die guten Erklärungen

Jester

Naja, das Framework kannste Dir runterladen. Aber es ist dennoch ne Menge Aufwand die ganzen Tests zu schreiben. Wenn man sie mal hat isses ja schön...

Ich weiß auch nicht, ob es Sinn macht sowas in bestehende Projekte zu integrieren. Wahrscheinlich hat man dann nicht so recht Lust und testet nur oberflächlich. Das ist dann unter Umständen schlechter als garnicht... man neigt irgendwie dazu mit der Zeit zu sagen: Der Code hat die Tests bestanden, also ist er per Definition korrekt. Das ist dann möglicherweise sogar kontraproduktiv.

Shade Of Mine

TheBigW schrieb:

Mhh, wortwörtlich nur auf Vorbedingungen? Ich teste damit an allen Stellen (auch Rückgabewerte), wo ein Fehlschlagen richtig weh tut.

Jo, so ists richtig. Meistens testet man damit lediglich vorbedingungen aber nicht ausschliesslich