Systemtests
-
1. Kompilieren, kopieren, starten, läuft oder läuft nicht
2. Gar nicht, nö.
3. Nö.
4. Gar nicht.Als Entwickler kümmert mich das nicht, dafür gibt es ganze Testabteilungen.
-
Privat:
1. Kompiliert? -> Manueller Test erfolgreich? -> Testsuite erfolgreich durchgelaufen? Wobei ich nicht für jede kleine Änderung alles von vorn bis hinten durchlaufen lasse, nur eben "oft genug"
2. Boost.Test, kleine Perlscripte, die den Input simulieren,... je nach Größe des Projekts
3. Link nicht, aber Buch: Clean Code | ISBN: 0132350882 - man muss sich selber überlegen wie viel von dem TDD-Wahn man sich zu Eigen machen will, der dort vorgestellt wird.
4. Nur was nicht durch die Unit-Tests abgedeckt wird. Siehe 2., Perl-Scripte, soweit das geht.Dienstlich:
1. Kompilieren, manuell testen, "startentwicklertest" in die Konsole eingeben und drauf warten dass der Testserver losnudelt. Nach ner Weile gibts dann ne Mail. Danach einchecken und dem Testteam Bescheid geben zum Nachtesten.
2. Ein Tool dass tatsächlich die GUI-Klicks durchnudelt. Der Entwicklertest dauert auch entsprechend lang (bis zu 3 Stunden). Marke Eigenbau, made by Kollegens.
3. -
4. Es wird fast NUR das komplette System getestet.
-
Boost.Test und ggf. gcov fürs coverage testing und CTest zum ausführen der Tests. (Bei externen Abhängigkeiten, dann eben dummy Skripte. Aber so was ist immer blöd zu testen und oft findet man nur Bugs in den mal eben gehackten dummy Skripten)
Gehört wohl eher in das rudpf
-
Dieser Thread wurde von Moderator/in pumuckl aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
zu 1.)+2.)
wir schreiben Unit-Tests (Framework boost.test), die auch in einem TestAll.bat alle automatisch durchlaufen werden können. Die Testabdeckung ist aber eher gering; ich versuche zumindest nach einer Fehlermeldung einen Test zu schreiben, der den Fehler hervorruft und der nach behobenen Fehler dann ok sein muss.
Das Gesamtsystem wird nach jeder relevanten Änderung manuell vom Entwickler geprüft (Starten, gucken ob das geht, was man meint, dass es gehen soll und gut).
Eine freigegebene Version wird durch einen dritten Kollegen noch einem Integrationstest unterzogen, dieser Test ist aber oft nur wenig mehr als ein Smoketest.zu 3.) <http://clean-code-developer.de/wiki/CcdWerkzeugliste#AutomatisiertesTesten>, habe aber mit den Tools aus der Liste keinerlei Erfahrung.
zu 4.) Integrationstest (s.o.)
Bem.: Da ich z.Zt. selber Testsoftware schreibe, sitzen meine 'Kunden' dicht bei mir, und kommen vorbei, falls was nicht geht.
Aber auch diese Testsoftware muss selbst getestet werden.Gruß
Werner
-
-
Danke für eure Erfahrungen!
Es ist wirklich interessant die verschiedenen Meinungen zu diesem Thema zu hören. Dennoch glaube ich einige Gemeinsamkeiten ausgemacht zu haben.
Ich hoffe, es stört euch nicht, wenn ich nochmal bei den Dingen nachhake, die ich nicht verstanden habe...Boost.Test und ggf. gcov fürs coverage testing und CTest zum ausführen der Tests. (Bei externen Abhängigkeiten, dann eben dummy Skripte. Aber so was ist immer blöd zu testen und oft findet man nur Bugs in den mal eben gehackten dummy Skripten)
Was bedeutet coverage test und was ist CTest?
Eine freigegebene Version wird durch einen dritten Kollegen noch einem Integrationstest unterzogen, dieser Test ist aber oft nur wenig mehr als ein Smoketest.
Unterscheidet sich der Integrationstest Deines Kollegen nur inhaltlich (benutzt er zum Beispiel nur eine andere TestAll.bat) oder auch von der Technologie (benutzt er etwas anderes als Boost.Test)? Ich werde mir dieses Boost Test Framework morgen auf der Arbeit auf jeden Fall mal ansehen!
1. Kompiliert? -> Manueller Test erfolgreich? -> Testsuite erfolgreich durchgelaufen? Wobei ich nicht für jede kleine Änderung alles von vorn bis hinten durchlaufen lasse, nur eben "oft genug"
2. Boost.Test, kleine Perlscripte, die den Input simulieren,... je nach Größe des Projekts
3. Link nicht, aber Buch: ISBN:0132350882 - man muss sich selber überlegen wie viel von dem TDD-Wahn man sich zu Eigen machen will, der dort vorgestellt wird.
4. Nur was nicht durch die Unit-Tests abgedeckt wird. Siehe 2., Perl-Scripte, soweit das geht.Danke für die konkreten Punkte!!
Wie baust Du denn Deine Testsuite?
Warum hast Du Dich für Perl entschieden? Welches Interface benutzt du, um aus Perl C++ Code auszuführen?Danke danke danke.
Viele Grüße und einen schönen Abend noch.
Raph
-
Code Coverage Tests sind normalerweise dafür da, dir anzuzeigen, wieviel Zeilen Code durch deine Tests abgedeckt sind (interessant für verschiedene if-Zweige). Wenn du dann z.B. als Entwicklungsumgebung Eclipse hast, gibt es Plugins dafür, die dir nach durchlaufenen Unit-Tests den Code, der getestet wurde, grün anzeigen, und den ungetesteten rot! Ich nehme mal an, dass das damit gemeint ist
-
Raphw schrieb:
Boost.Test und ggf. gcov fürs coverage testing und CTest zum ausführen der Tests. (Bei externen Abhängigkeiten, dann eben dummy Skripte. Aber so was ist immer blöd zu testen und oft findet man nur Bugs in den mal eben gehackten dummy Skripten)
Was bedeutet coverage test und was ist CTest?
Coverage test hat beselbube ja schon erklärt (Geht halt darum zu sehen, wieviel Code die Tests abdecken). CTest ist ein Teil von CMake, damit kann man gezielt Unittests ausführen und auswählen und die Ergebnisse dann an einer zentralen Stelle (zB CDash) sammeln.
-
Raphw schrieb:
Danke für die konkreten Punkte!!
Wie baust Du denn Deine Testsuite?
Warum hast Du Dich für Perl entschieden? Welches Interface benutzt du, um aus Perl C++ Code auszuführen?Was meinst du mit "bauen"? Wenn du das erstellen meinst (also nicht den "build"), dann gehts wie folgt:
- ich brauche neue Funktionalität
- ich schreibe einen (oder mehrere) Tescases dafür in die Testsuite (oder eine eigene Testsuite)
- ich schreibe die Funktionalität, erst danach compilieren meine Testcases überhaupt.
- ich korrigiere die Funktionalität, bis die Testcases richtig laufen.