JLI Spieleprogrammierung

[xardias]

Servus allerseits,

ich wollte euch mal mit Testgetriebener Programmierung vertraut machen.
Wie mache sicher wissen bastel ich an einem web Framework für Java und bind darüber auf diese Methode gestoßen.

Kurz beschrieben funktioniert da ganze so (wikipedia):

1. Schreibe einen kleinen Test für den nächsten zu implementierenden Funktionalitätshappen. Dieser Test sollte nicht funktionieren.
2. Erfülle den Test mit möglichst wenig Code, um schnell wieder zum "grünen Balken" (alle Tests laufen) zurückzukehren.
3. Räume den Code auf, dazu gehört die Entfernung von Duplikation, Einführung von notwendigen Abstraktionen und Umsetzen der Codekonventionen. Ziel dieses Aufräumens ist die einfache Form des Codes.

Am Anfang war ich ziemlich skeptisch und hab das ganze für totalen Schwachsinn gehalten. Wie soll ich etwas testen was ich noch nichtmal geschrieben habe? Aber dann habe ich das Buch "Testgetriebene Entwicklung mit JUnit und FIT" gelesen und war nach ca 10 Seiten absoluter Test-Junkie.

Spontan habe ich angefangen das ganze auf mein Projekt anzuwenden und bin ziemlich begeistert von den Methoden. Ich habe das Projekt in kleine Häppchen aufgeteilt. U.a. ein sog. ServiceManager welcher dafür zuständig ist Services zu laden, starten, und Abhängigkeiten unter ihnen zu verwalten.
Anstatt einfach eine Klasse dafür zu Programmieren schreibt man einen Test der vllt so ausschaut:

[The Lord of Programming]

Du bist verrückt

*lol* nein...hab mich mal ein bisschen in das Thema eingelesen und finde es ziemlich interessant
Wenn ich mich nicht irre, wird dieses Testsystem sogar bei den Coding4Fun-Videotuts eingesetzt.

Ich bin mir jetzt noch nicht sicher, ob ich es richtig verstanden habe, aber wäre diese Methodik nicht mit einem (evtl. etwas veränderten aber auf jeden Fall) ausgeprägten Logging-System zu vergleichen?
Die Implementierung finde ich auf den ersten Blick etwas komisch und umständlich. Aber wäre es nicht genauso möglich - ohne für jeden einzelnen Test eine neue Testklasse inklusive Testrumpf schreiben zu müssen - das direkt einzubauen?
Also praktisch Pseudocode...:

[Jones]

Du irrst dich nicht Lord of Programming, diese Technik wird in den Coding4Fun Videos eingesetzt und das ist auch gut so. Ich schreib im moment ein 2D Engine in C# und da ist es, wie xadrias schon gesgat hat, viel motivierender weil man sieht was man geschaffen hat
edit: für .NET Sprachen gibt es das NUnit Framework zum testen

[KI]

@TLoP
Ich finde es wesentlich unübersichtlicher, wenn die Tests kreuz und quer mitten im Programmcode verstreut sind.

Man wird die erstellten Klassen sicher mehr als einmal benutzen. Soll man dann für jede Implementierung den Testcode mit einbinden!? Dadurch wird der Code doch nur unnötig aufgeblasen.

Ich finde die Idee mit den Testfunktionen auf den ersten Blick interessant. Außerdem wird der liebe Compiler die Testfunktionen im fertigen Programm nicht mitkompilieren, sofern sie nie benutzt werden.

edit: Ich hab den Thread mal nach Entwicklung geschoben, sonst wird er noch Opfer des Prunings.

[Kampfhund]

Ich habe schon häufiger Test-Klassen für einzelne Klassen, die ich programmiert habe, geschrieben. Allerdings habe ich diese immer nachher geschrieben.

In meinem Informatik Studium wurde uns die Test-Getriebene-Entwicklung mit JUnit auch beigebracht. Wir sollen da ständig Test-Klassen für alles mögliche erstellen. Ich habe noch nicht viel Erfahrung mit dieser Art der Programmierung. Mal sehen, wie sich das so entwickelt.
_________________
Kochen ist ein NP-schweres Optimierungsproblem.

[xardias]

Naja, tests wird jeder schonmal geschrieben haben. Aber bei der Testgetriebenen Entwicklung steht das im Mittelpunkt.
Das heißt nicht dass man mehr Zeit mit Tests verbringt als mit dem Programmieren, aber man nutzt die Tests praktisch dazu zu definieren was genau das Feature welches man implementiert an Funktionen haben muss und wie es sich in Fehlerfällen verhält.

Wie gesagt ich fand es Anfangs auch nicht so toll. Aber wenn man sich mal darauf eingelassen hat statt studenlang über ein design zu grübeln einfach mit einem simplen Test ganz unten anzufangen und sich langsam nach oben hinnauf zu arbeiten dann funktioniert das sehr gut.
Die erfüllten Tests motivieren einen weil man das Gefühl hat dass man etwas funktionstüchtiges geschafft hat und man macht sich viel mehr Gedanken darum wie genau das Verhalten der Klasse eigentlich definiert sein soll.

Natürlich trenne ich auch Test und Anwendungs Code in 2 verschiedene Source Ordner.
Wer mal schauen will:
http://svn.dev-area.net/screws/core/src/
im main Ordner ist der Anwendungs Code und um im Test Ordner sind die Test Klassen. Bisher auch nur zum ServiceManager.

PS: Es soll sogar Leute geben die wenn sie eine Bibliothek verwenden statt die Dokumentation zu lesen sich die Test Klassen anschauen ^^

[The Lord of Programming]

[xardias]

[proggaholic]

Joah, hört sich gut an. Bei uns im Geschäft wird auch Wert darauf gelegt, dass man einzelne Module schreibt, erst als stub/black box/etc, und dann für Implementierung sorgt, die einzeln und gesamt getestet wird, um Fehler herauszufiltern. Klar sieht dein Konzept da anderst aus, nur kann ich mir schwer vorstellen, wie das funktionieren soll, wenn man im Projekt feste Vorgaben hat. Daheim und Privat werd ichs mir nun auch mal anschauen, aber im Betrieb gibts nen Pflichtenheft und ne deadline, ausserdem will der Chef schöne Struktogramme/UML/Flussdiagramme/etc. sehen, da wäre dann die Frage, ob dort solche bottom-up-Konzepte ebenfalls einsetzbar wären...

[PeaceKiller]

So kann das funktionieren:
http://www.gamesfromwithin.com/articles/0603/000107.html

oder im Arbeitsalltag:
http://www.gamesfromwithin.com/articles/0602/000104.html
_________________
»If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year, killing everyone inside.«
– Robert X. Cringely, InfoWorld magazine

[xardias]

[proggaholic]

hmmm, gut, also wenn die Technik das entsprechende Potential hat (wie es ja den Anschein hat), wird es sich auch durchsetzen...hoffentlich auch bei uns ;)

xardias
Gibt es eigentlich auch noch andere empfehlenswerte Bücher in diese Richtung? Ich hab ein bisschen umhergeschaut und ausser dem von dir vorgestellten kein weiteres entdecken können, das sich hauptsächlich damit beschäftigt...oder ist es noch zu neu?

[The Lord of Programming]

Da ich glaube, dass der Ansatz und nicht die Umsetzung hier entscheidend ist, hab ich mir mal eine kleine Utility geschrieben. Mir gefällt das irgendwie nicht so ganz mit dem Auslagern in Klassen etc...

Jedenfalls kann man es jetzt so benutzen(habe ein Beispiel aus einem von PeaceKiller geposteten Link gewählt und nach meiner Umsetzung abgeändert):

[xardias]

Ist auf jeden Fall ein guter Ansatz, aber das Ziel der Testgetriebenen Programmeirung ist es ja kontrollierte Testfälle zu entwickeln, daher ist es dort schon wichtig den Test Code auszulagern, indem man einzelne kleine Komponenten gesondert testet.
Dann kann man davon Ausgehen, dass diese Komponenten ein genau definiertes Verhalten haben und diese so nutzen.
Wenn man die Tests erst bei der Verwendung macht verfehlt man damit eigentlich das Ziel der testgetriebenen Programmierung, da man dort ja auch die Tests VOR dem code schreibt.

[The Lord of Programming]