Wie programmieren über Test-cases?
-
Hallo,
ich lese/höre immer wieder dass man ohne Test-cases eigentlich nicht programmieren sollte bzw. immer darauf achten sollte, daß man auch so codet dass wenn man mal was dazuprogrammiert dass man einfach über den testcase feststellen kann dass man nichts intern zerschießt.
Meine Frage(n):
Ich möchte gerne ein numerisches programm schreiben und würde gerne diese testproblematik mit einbauen. Wie sollte ich vorgehen - wie macht ihr das bzw. welche techniken nehmt ihr her? Mir fehlen leider jegliche Erfahrungswerte.
-
Wie geht ihr vor? Schreibt ihr zuerst immer den testcase und dann die funktion (falls ihr funktions-weise testcases habt) und wenn ja - wie sieht dass dann aus (könnt ihr ein kleines beispiel geben?).
Oder wie benutzt ihr so testcases. -
Ich weiß dass sowas Zeit frißt aber gibt es da vielleicht auch kleinere Test-Sachen die man miteinbaut die nicht so viel Zeit kosten?
-
Und wie trennt ihr sowas vom restlichen code? Über Präprozessor-direktiven?
Danke euch
-
-
-
Ok danke schonmal. Und ist das auch euer übliche Weg - macht ihr das so wie in der Doku beschrieben oder habt ihr eigene Wege?
-
WeißBier schrieb:
ich lese/höre immer wieder dass man ohne Test-cases eigentlich nicht programmieren sollte bzw. immer darauf achten sollte, daß man auch so codet dass wenn man mal was dazuprogrammiert dass man einfach über den testcase feststellen kann dass man nichts intern zerschießt.
Test-Driven-Development ist meiner Meinung nach als generelle Regel Unfug. Dazu kommt es viel zu sehr auf die Art der Anwendung, die Menge und Komplexität des Codes, das Programmierteam und vieles mehr an. Ich persönlich halte mehr davon, gezielt "unsicheren" Code zu testen, oder Code, dessen Ergebnisse man beim Test-Lauf nicht oder nur schwer überprüfen kann.
Der imo größte Vorteil beim Tests-First-Konzept ist, dass man nicht "ins Blaue" programmiert, man legt das Verhalten schon vorher strikt fest (inklusive der Grenzfälle, invalider Eingaben usw). Das kann man aber auch anders erreichen, z.B. durch Formulierung von Pre-/Postconditions.Hier noch ein sehr schönes Zitat:
http://joelonsoftware.com/items/2009/01/31.html schrieb:
Yeah, it's a balancing act. And I don't want to come out and say I'm against [unit] testing, because I'm really not. Anything that improves quality is good. But there's multiple axes you're working on here; quality is just one axis. And I find, sadly, to be completely honest with everybody listening, quality really doesn't matter that much, in the big scheme of things...
-
WeißBier schrieb:
- Ich weiß dass sowas Zeit frißt aber gibt es da vielleicht auch kleinere Test-Sachen die man miteinbaut die nicht so viel Zeit kosten?
Jopp, es gibt "andere, kleinere Sachen", z.b. assert()
(mit Betonung auf "andere", denn Assertions nicht natürlich nicht genau dasselbe wie Test-Cases. Allerding multiplizieren Assertions IMO die Nützlichkeit von Test-Cases, sowie bringen auch ganz ohne Test-Cases schon viel)
-
hmm danke... wie geht ihr denn vor wenn ihr was programmiert? Erstellt ihr keine Test-Cases im Nachhinein oder derartiges? Geht ihr rein straight forward vor?
-
Erstellt ihr keine Test-Cases im Nachhinein oder derartiges?
Doch, genau das mache ich öfters.
Man schreibt ja oft mal irgendwelchen Test-Code, um abzusichern dass irgendwas bis Punkt X passt. Damit man später nicht einen Riesen unüberschaubaren Haufen Code hat, und *irgendwas* tut nicht wie es soll, und man darf sich dann dämlich suchen.Anstatt diese kleinen Test-Schnipsel wegzuwerfen oder irgendwo auskommentiert rumgammeln zu lassen, mach' ich einfach Test-Cases draus.
-
Anstatt diese kleinen Test-Schnipsel wegzuwerfen oder irgendwo auskommentiert rumgammeln zu lassen, mach' ich einfach Test-Cases draus.
hmm hast du ein kleines beispiel wie du da vorgehst? Präprozessor oder wie?
-
Test-driven Development ist eine große Umstellung, wenn man es nicht von Anfang an so gelernt hat. Der Grundgedanke ist gut, aber die Macht der Gewohnheit lässt einen das nicht durchhalten.
Da ich selber immer alles iin Libraries entwickle (also ohne main-Funktion), bin ich gezwungen Testcases zu programmieren. Dabei handelt es sich um eigenständige Mini-Programme (mit eigener main-Funktion). Ich erstelle aber meistens nicht zu erst den Testcase, sondern fange die Library-Funktion/Klasse an, und ab einem gewissen Punkt, wo ich es testen will/muß, wird das Testcase erstellt.
Ich benutze dafür aber keine Testsuite. Ich benutze einfach assert oder if-else-Konstrukte. Es wäre aber sicherlich angebracht, das ich mich mal wieder mit Testtools befasse. Ich hatte mal Boost-test probiert, hatte mich aber nicht so begeistert.
-
So ein Kram verwende ich auf der Arbeit eigentlich gar nicht. Das System ist einfach viel zu komplex als daß sich da viel rauslösen lassen würde. Gerade wenn noch Netzwerk, Shared Memory, Taktgeber etc. hinzukommen, wird es schwierig da echt Fälle zu rekonstruieren. So sich eine Methode aber extrahieren läßt, wird diese entsprechend getestet. Aber vielleicht auch nur einmal pro Jahr.
Im Endeffekt ist das Management auch gar nicht bereit die Entwickler für sowas zu bezahlen, schließlich gibt es dafür ja die QA-Abteilung. Das die aber nur Blackbox-Tests durchführen kann, und dies nur für das gesamte Software-/Hardwarepaket, interessiert da keinen.
-
Ein Test-Case zu erstellen bevor man die Klasse erstellt bzw. eine Komponente hat den Vorteil, dass man sich überlegt wie das Interface aussehen und sich verhalten soll (zumindest in groben Zügen). Daher erstelle ich oft zuerst einen Test-Case, da ich mir ja sowieso zu einem Zeitpunkt Gedanken über das Interface machen muss und in echtem Code hat man den Vorteil, dass man das Interface gleich so hat wie man es haben will.
Wirklich Fehler finden kann man mit Test-Cases aber nur sehr eingeschränkt, da die Code-Komplexität zu groß ist, dass man niemals alle Möglichkeiten durchprobieren kann und oftmals gar nicht abschätzen kann welche Teile wirklich die Problematischen sind. Dafür würde ich zu Fuzzy Testing raten.
-
Profi-Tester schrieb:
Wirklich Fehler finden kann man mit Test-Cases aber nur sehr eingeschränkt, da die Code-Komplexität zu groß ist,
Das ist Blödsinn.
Hast du etwa das Wort alle vergessen? Denn "wirklich alle Fehler" finden kann man natürlich nicht. Allerdings egal wie. Auch nicht mit [insert-extra-catchy-buzzword]-Testing. Ehrlich.Aber viele viele Fehler findet man trotzdem mit Unit-Tests. Darunter etliche die man sonst u.U. garnicht, oder erst sehr spät gefunden hätte.
