Testet ihr eure Software automatisch?
-
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.
-
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?