Testet ihr eure Software automatisch?
-
Tobiking2 schrieb:
Bei TDD sehe ich den großen Vorteil darin das man zuerst einmal das Design überprüft. Beim Schreiben eines Unittest merkt man direkt ob man irgendwo einen Klumpen an festen Abhängigkeiten geschaffen hat, oder eine Schnittstelle entworfen hat die von Außen gar nicht vernünftig aufgerufen werden kann.
Ergänzend dazu: Man denkt auch mehr über das Design nach, auch jenseits von Abhängigkeiten. Es hilft Fallstricke schon im Vorfeld zu erkennen, und auch Wertebereiche etc. von Übergaben zu hinterfragen.
Tobiking2 schrieb:
In dem Sinne sehe ich gar kein Problem wenn man erstmal drauf los programmiert. In den meisten Fällen wird darauf ein Umbau oder Refactoring folgen, vor dem man dann die Tests schreiben kann um einen ähnlichen Effekt zu erreichen.
Ich weiß nicht wie du arbeitest, nach meiner Erfahrung macht man es sich mit nachträglichen Tests wesentlich einfacher, im Sinne von "Ich weiß ja das es funktioniert". Denkt man beim nachträglichen Schreiben von Unittests wirklich so genau über mögliche Fehler und Designentscheidungen nach, oder überwiegt nicht doch die Faulheit, weil der Code ohnehin da ist? Überwindet man wirklich den inneren Schweinehund über gemachte Arbeit nachzudenken?
-
asc schrieb:
Denkt man beim nachträglichen Schreiben von Unittests wirklich so genau über mögliche Fehler und Designentscheidungen nach, oder überwiegt nicht doch die Faulheit, weil der Code ohnehin da ist?
Also mir sind die Fallstricke normalerweise nach der Implementierung viel klarer als vorher.
-
asc schrieb:
Ich weiß nicht wie du arbeitest, nach meiner Erfahrung macht man es sich mit nachträglichen Tests wesentlich einfacher, im Sinne von "Ich weiß ja das es funktioniert". Denkt man beim nachträglichen Schreiben von Unittests wirklich so genau über mögliche Fehler und Designentscheidungen nach, oder überwiegt nicht doch die Faulheit, weil der Code ohnehin da ist? Überwindet man wirklich den inneren Schweinehund über gemachte Arbeit nachzudenken?
Aber woher weiß man denn das es funktioniert? Üblicherweise doch dadurch das man den Code ausführt und ein paar Beispiele ausprobiert. Dabei hat man meist schon ein paar Fälle im Hinterkopf die kritisch sein könnten. Die ideale Basis für Unittests.
Der Knackpunkt ist dann eigentlich nur wie aufwändig das Schreiben des Tests wird. Mit einem vernünftigen Test- und Mockingframework sollte man einen Test für eine Klasse ohne feste Abhängigkeiten recht fix runterschreiben können. Und verschiedene Fälle sind dann oft nur noch copy-paste und Werte anpassen.
Ich muss allerdings auch sagen das bei uns eher der Fall vorkommt das wir fremden Code testen. Wenn wir Änderungen oder Erweiterungen an Software (die schon "funktioniert") durchführen, können wir mit Tests den Ist-Fall abdecken und teilweise auch aufdecken das sie in bestimmten Fällen doch nicht korrekt arbeitet.
-
Tobiking2 schrieb:
asc schrieb:
Ich weiß nicht wie du arbeitest, nach meiner Erfahrung macht man es sich mit nachträglichen Tests wesentlich einfacher, im Sinne von "Ich weiß ja das es funktioniert"...
Aber woher weiß man denn das es funktioniert? Üblicherweise doch dadurch das man den Code ausführt und ein paar Beispiele ausprobiert. Dabei hat man meist schon ein paar Fälle im Hinterkopf die kritisch sein könnten. Die ideale Basis für Unittests.
Man weiß das es funktioniert, wenn man anschließend Implementiert und die Tests ausführt. Man sollte bereits in der Designphase die Anforderungen kennen, und nicht die Testdaten aus dem Codeablauf herleiten. Dabei übersieht man häufig eher etwas. Es ist nicht ohne Grund so das Fehler und Anforderungen um so teurer werden, um so später diese auffallen/anfallen. Ich habe grob den Faktor 10 je Phase in Erinnerung: Planung (1x), Entwicklung (10x), Test (100x), Auslieferung (1000x).
Unittests dienen unter anderem dazu Code gegenüber der Spezifikation (aus der Planung), nicht der Entwicklung zu prüfen. Selbst in so einer kleinen Firma wie hier, wo es (meist) keine Dokumente aus der Planung gibt, existieren dennoch Spezifikationen und sei es in Form einer kleinen Anforderung im Bugtracking-System. Und was dort gewünscht wird, sollte auch getestet werden.
Ich zumindest habe bei meinen kurzen privaten TDD-Ausflügen festgestellt das es tatsächlich besser ist Tests im Vorfeld zu schreiben. Nur fehlt dafür den meisten Entwicklern die Disziplin. Wenn man erst einmal herunter schreibt kommt es weit eher dazu das man Testfälle vergisst (weil es ja läuft). Tests nachträglich zu schreiben ist in etwa so als würde man ein Haus bauen und erst nach dem letzten Handschlag im Abschluss die Arbeit überprüfen. Da übersieht man aber ob unter dem Putz Schäden sind etc.
Merkwürdigerweise (und da nehme ich mich nicht aus) sind Softwareentwickler meist die Personen, die meinen alles ohne genauere Spezifikationen sauber entwickeln zu können. Wenn man sich anschaut wie viele Fehler ein typisches Softwareprodukt aufweist (gibt dazu ja wirklich genügend Studien) sollte dies einem zu denken geben.
-
es kann sehr wohl sinnvoll sein, Testfälle aus dem Code herzuleiten, beispielsweise um für beide Zweige einer (jeder) if-Anweisung Testfälle zu haben, oder gezielt Grenzfälle testen, um off-by-1-errors zu detektieren, Fehlerzustände zu provozieren, um zu testen, ob diese korrekt behandelt werden usw
-
großbuchstaben schrieb:
...Testfälle aus dem Code herzuleiten, beispielsweise um für beide Zweige einer (jeder) if-Anweisung Testfälle zu haben,...
Du programmierst wohl gegen die Implementierung und nicht die Schnittstelle, nehme ich mal an...
-
Manche Leute brauchen 100% Abdeckung, da muß man dann auch auf die Ergebnisse reagieren.
-
Tyrdal schrieb:
Manche Leute brauchen 100% Abdeckung, da muß man dann auch auf die Ergebnisse reagieren.
1. Es ist das eine nachträglich Tests zu ergänzen und anzupassen, als diese erst nachträglich zu schreiben (mit der großen Gefahr nur den Code wie er ist zu testen ohne Anforderungen etc. zu berücksichtigen).
2. Ein Test soll das SOLL dokumentieren und absichern und nicht das IST.
3. TDD soll auch zu schlankeren Code führen, weil man eben genau das umsetzt, was auch durch Anforderungen und Tests gefordert ist.
-
Unittests gehen noch klar. Die sorgen auch dafür, dass die Unit wiederverwendbar ist, schließlich muss die Unit irgendwie im Test kompilieren (ohne den ganzen anderen Rest). Hatte mal ein Projekt wo Geräte verschiedenster Hersteller Daten laut Standard schicken sollen. Also zack, solche Daten besorgt und Unittests für den Parser geschrieben.
Das ist schon ein angenehmes Gefühl, wenn man eine Änderung in der Bibliothek macht, comitted und auf dem Server sofort für jedes Geräte geprüft wird, ob die Software noch so läuft wie vorher
-
Wie Integrationstest in der Praxis funktionieren sollen ist mir schleierhaft, vlt. mag jemand was dazu erläutern?