Da sollte man beinahe einen eigenen Thread für aufmachen.
...wenn ich in der Lage bin die richtige Testroutine zu schreiben, kann ich auch den "richtigen" Code schreiben....Bzw. die Fehler, die heute in "unseren" Programmen auftreten sind genau die, die eine Testroutine auch nicht gefunden hätte.
Die Unittests dienen dazu, die Funktion des zu testenden Objekts (bzw. die eine Methode) sicherzustellen. Du nimmst Dir die Spezifikation der Methode ('Was soll die eigentlich machen?') Und schreibst Tests dafür, und zwar für jeden Anwendungsfall (=Kombination der Parameteräquivalenzklassen*) einen eigenen Test. In deiner Testroutine kommt kein einziges IF vor, keine Schleife. Daher sind die Testroutinen auch viel einfacher zu schreiben, als der zu testende Code.
(* Bei der Funktion 'Schuhe ab Größe 45 sind kosten 5 Euro mehr') haben wir einen Parameter (Schuhgröße) mit zwei Äquivalenzklassen: Größen bis 45 und Größen ab 45. Man testet dann mit einem Wert aus jeder Klasse, sowie 1-2 Werten aus den Grenzen zwischen den Klassen, also: 30, 44,45,46, 50. Genauergenommen haben wir hier 5 Tests!)
So, nun hast Du also Code, der deinen eigentlichen Code testet, bzw. eine Aussage treffen kann, ob der Code das macht, was er machen soll. Super und ziemlich banal das Ganze.
Nun kommt eine Änderung rein, oder eine Optimierung, ein Refactoring o.ä. Mit deinen Testroutinen kannst du munter drauflosoptimieren, redigieren, verändern usw. Solange dein Test 'grün' ist, ist die Welt in Ordnung. Zum Schluß noch eine Verifikation am lebenden Objekt und Du kannst dir nun ziemlich sicher sein, das der Kunde nicht gleich anruft und sich beschwert.
Findet der Kunde einen Bug, ist klar, das Du keine 100% Codeabdeckung hast, und dieser blöde Käfer durch die (Test-) Maschen geflutscht ist. Aber weil Du schon Tests geschrieben hast, schreibst Du halt noch einen Test, der den Bug prüft (so ein Bug ist ja i.a. nur fehlerhaftes Verhalten bei bestimmten Eingabeparametern). DIESER Bug wird nie wieder auftreten, egal an welchen Schrauben Du in Zukunft noch drehen wirst.
Zitat:
aber was ist mit unzähligen Routinen die man immer verwendet?
Gerade die sind es wert, mit Unittests in Stein gemeißelt zu werden. Der älteste Bug, den ich in meiner Library entdeckt habe, schlummerte 10(!) Jahre im Code.
Zitat:
Bist Du der Meinung es loht sich im nachhinein dafür Testroutinen zu schreiben?
Es ist nie zu spät. Einziger Nachteil: Man gerät in Versuchung, sich den Code anzuschauen, um dann einen Test zu schreiben. Damit testet man dann nicht mehr 'was soll der Code machen?' sondern 'was macht der Code zur Zeit?'. Das ist ok, wenn der Code korrekt ist, aber ein wenig problematisch, weil man im schlimmsten Fall Tests für Bugs mit implementiert. Aber es ist immer noch 10000x besser als gar nichts.
TDD (Test Driven Development) ist ja so, das zuerst Testcode für eine zu implementierende Funktionalität geschrieben wird und danach erst die Funktionalität selbst. Ich mag das nicht, weil man den eigentlichen Code zu sehr an den Testcode anlehnt. Man schreibt also nicht guten Code der auch gut testbar ist, sondern in erster Linie einfach testbaren Code. Da leidet die Lesbarkeit ein wenig. Muss aber jeder selbst herausfinden.
Wir machen das so, das wir eine Businessoperation implementieren und gleich dazu die Tests für Validierung und Persitierung. Danach das Viewmodel und Kommandos und gleich die Tests dafür. Ich habe Basiskommandos durchgesetzt, wobei die Grundlogik in der abstrakten Klasse umgesetzt ist (sowas Banales wie: 'Es sind ungespeicherte Änderungen. Speichern? [Ja] [Nein] [Abbrechen]'). Dieses Verhalten wird einmal getestet und alle abgeleiteten Kommandos teste ich nur noch, ob sie vom Basiskommando ableiten und dann noch, ob die überschriebene Methode das macht, was sie machen soll.
Anfangs ging das etwas ruckelig mit den Tests und einige der Programmierer wissen immer noch nicht, was sie eigentlich testen sollen, aber mit der Zeit gewöhnt man sich daran. Ich schreibe mittlerweile das Formular zum Schluss, sozusagen als Sahnehäubchen. Denn ich weiß ja, das Operation, Viewmodel etc. super funktionieren. Das ist das komplette Gegenteil von
RAD, aber auch nicht schlecht. Man muss eben mehr planen und mit Wireframes arbeiten.
Vielleicht sollt aber der "arme SW-Entwickler" einfach seine Aufwandsabschätzungen immer nur incl. Test und Dokumentation abgeben und diesen Punkt nicht extra ausweisen?
Das Problem an der Sache ist ja, das die Konkurrenz so schlampig ist, und ohne Unittests programmiert. Die sind vom Aufwand her eben um 40-60% günstiger.
Gottseidank macht sich Qualitätsbewustsein langsam bei den Kunden bemerkbar: Eine Anforderung eines großen deutschen Krankenkasse (
SOAP-Anbindung) musste inklusive Architektur und Unittests umgesetzt werden (Vorgabe der IT-Abteilung). Klasse.
Ich merke gerade: Ich hab Ferien und sülze hier rum...