Testet ihr eure Software automatisch?
-
asc schrieb:
* Meines Erachtens rentiert sich automatisches Testen vor allem bei Software die Langlebig ist (typische Produktentwicklung), wo der Aufwand die Tests zu schreiben weit geringer als die Wartungszeit ist. Bei kleinen oder sehr kurzlebigen Projekten würde ich eher darauf verzichten.
Da lohnt es sich auch, damit das Projekt klein und kurz bleibt.
-
TyRoXx schrieb:
asc schrieb:
* Meines Erachtens rentiert sich automatisches Testen vor allem bei Software die Langlebig ist (typische Produktentwicklung), wo der Aufwand die Tests zu schreiben weit geringer als die Wartungszeit ist. Bei kleinen oder sehr kurzlebigen Projekten würde ich eher darauf verzichten.
Da lohnt es sich auch, damit das Projekt klein und kurz bleibt.
Das mag sein, aber ob man dies gegenüber einer Geschäftsleitung durch bekommt ist weitaus fraglicher, als wenn man über den langfristigen Nutzen in einer Produktentwicklung argumentiert. Zuerst werden automatische Tests als Mehraufwand angesehen (sehe ich auch so, man muss aber immer auch den Nutzen abwägen) und einige Entwickler sehen auch keine Notwendigkeit daran, Test vor dem Code zu schreiben.
-
Also ich persönlich kann auch gar keine Tests vor dem Code schreiben. Bei mir ändert sich am Anfang während der Entwicklung eines Features so schnell soviel, daß ich am Anfang noch gar nicht weiß weelche Units es überhaupt geben wird.
-
Tyrdal schrieb:
Also ich persönlich kann auch gar keine Tests vor dem Code schreiben. Bei mir ändert sich am Anfang während der Entwicklung eines Features so schnell soviel, daß ich am Anfang noch gar nicht weiß weelche Units es überhaupt geben wird.
Dann wird bei dir noch weniger geplant als bei uns (und das ist nur sehr schwer denkbar ;p). Bei uns Ändern sich zwar Units, aber nicht so extrem das man für diese keine Tests schreiben könnte (bzw. man könnte die Tests entsprechend verschieben).
-
Im Gegenteil, es wird sehr viel geplant. Allerdings wird mir nicht vorgeschrieben wie ich zu implementieren hab.
asc schrieb:
bzw. man könnte die Tests entsprechend verschieben
Könnte man, aber dann wär ich sehr viel mit schieben beschäftigt.
-
Tyrdal schrieb:
Im Gegenteil, es wird sehr viel geplant. Allerdings wird mir nicht vorgeschrieben wie ich zu implementieren hab.
Mir auch nicht und dennoch habe ich kein solches Chaos.
Tyrdal schrieb:
asc schrieb:
bzw. man könnte die Tests entsprechend verschieben
Könnte man, aber dann wär ich sehr viel mit schieben beschäftigt.
Wenn es wirklich so viel zu verschieben gibt, könnte es aber durchaus auch daran geschuldet sein, das man ohne viel zu überlegen drauflos programmiert.
-
Das ist kein Chaos, und ja ich programmiere erstmal los, weil mir auf diese Weise die Probleme und deren Lösung schneller klar werden als durch reines Nachdenken. Da muss man dann, wenn man weiß wies denn werden soll auch mal was wegwerfen oder refactoren.
-
Tyrdal schrieb:
Im Gegenteil, es wird sehr viel geplant. Allerdings wird mir nicht vorgeschrieben wie ich zu implementieren hab.
Unittests testen niemals die Implementierung. Immer nur gegen die Schnittstelle (Input und Output).
Wo ist dein Argument gegen Unittests?
-
Artchi schrieb:
Wo ist dein Argument gegen Unittests?
Er hat doch gar nicht gegen Unittests geschrieben, seine Aussage war erstmal nur dass er sich nicht vorstellen kann Tests vor dem Code zu schreiben, weil er sich das Design erst beim Programmieren ueberlegt. Was IMO je nach Situation auch voellig okay ist. Wenn man Code in einem Bereich schreibt, in den man sich erst mal einarbeiten muss und wo einem noch nicht sofort bewusst ist, welche Architektur und welches Interface am sinnvollsten ist, ist das wahrscheinlich die produktivste Methode. (Insbesondere wenn man relativ isoliert arbeitet.) Wenn man natuerlich Module/Erweiterungen fuer ein grosses bestehendes Projekt schreibt, oder etwas in einem Bereich plant mit dem man bereits Erfahrung hat, ist das Interface eh mehr oder weniger klar, und dann kann man auch seine Tests gleich am Anfang schreiben.
-
cooky451 schrieb:
..seine Aussage war erstmal nur dass er sich nicht vorstellen kann Tests vor dem Code zu schreiben, weil er sich das Design erst beim Programmieren ueberlegt. Was IMO je nach Situation auch voellig okay ist. Wenn man Code in einem Bereich schreibt, in den man sich erst mal einarbeiten muss und wo einem noch nicht sofort bewusst ist, welche Architektur und welches Interface am sinnvollsten ist, ist das wahrscheinlich die produktivste Methode.
Ich persönlich habe bei solcher Vorgehensweise immer starke Bauchschmerzen, aus sehr schlechter Erfahrung. Manchmal geht es vielleicht nicht Anders, weil einem Informationen vorenthalten werden, aber auch das geht häufig früher oder später nach Hinten los (auch schon erlebt).
-
Artchi schrieb:
Wo ist dein Argument gegen Unittests?
Ich bin nicht gegen Unittests. Und selbstverständlich testen die die Implementierung. Ne Schnittstelle kan ich ja schlecht ausführen.
-
cooky451 schrieb:
Artchi schrieb:
Wo ist dein Argument gegen Unittests?
Er hat doch gar nicht gegen Unittests geschrieben, seine Aussage war erstmal nur dass er sich nicht vorstellen kann Tests vor dem Code zu schreiben, weil er sich das Design erst beim Programmieren ueberlegt. Was IMO je nach Situation auch voellig okay ist. Wenn man Code in einem Bereich schreibt, in den man sich erst mal einarbeiten muss und wo einem noch nicht sofort bewusst ist, welche Architektur und welches Interface am sinnvollsten ist, ist das wahrscheinlich die produktivste Methode. (Insbesondere wenn man relativ isoliert arbeitet.) Wenn man natuerlich Module/Erweiterungen fuer ein grosses bestehendes Projekt schreibt, oder etwas in einem Bereich plant mit dem man bereits Erfahrung hat, ist das Interface eh mehr oder weniger klar, und dann kann man auch seine Tests gleich am Anfang schreiben.
Genau das. Ich komm normalerweise in Projekte von denen ich keine Ahnung hab, aber sofort drin produktiv sein soll.
-
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.
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.
-
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.