Test-Frist Programmierung - wie vorgehen

[Kiel88]

Guten Tag,
kurz zu mir: ich bin im Java-bereich absoluter Anfänger. Ich kann kleinere Sachen mit entsprechenden Kontrollsturukturen programmieren und kann was mit Objektorientierung und Containerklassen anfangen. Ich muss nun innerhalb von 3 Wochen für eine Hausarbeit entsprechenden Quellcode schreiben. Grundsätzlich sind die Kentnisse soweit vorhanden, dass ich die Hausarbeit programmieren könnte. Allerdings ist eine Anforderung, dass nach Test-First Programmiert wird. Unser Dozent hat dazu leider kaum was in seinen Unterlagen. Ich schaue nun gerade, dass ich mich zeitlich effizient in das Thema einarbeite und möchte meine Strategie zur Einarbeitung rückversichern bzw. Tipps einholen, wie ich den Umgang bzw. das Programmieren von entsprechenden Tests am schnellsten lerne.
Zur Erstellung der Tests will ich auf Mockito als Framework zurückgreifen. Hierzu würde ich mich entsprechender Tutorials bedienen, um die Handhabung zu erlernen. Nun heißt es auch, dass zwingend zuerst die Tests geschrieben werden und anschließend erst der Quellcode. Ich habe schon grob eine Vorstellung, welche Klassen ich (ohne Tests) brauche, damit das Programm läuft. Ich habe momentan nur noch gar keine Ahnung, wie ich das Prinzip Test-First anwende.

Wie gehe ich hier am sinnvollsten vor?
1. Variante: ich lerne den Umgang von Mockito, schreibe kleine Tests runter und weiß dadurch dann automatisch, wie ich mit Test-First vorgehe in dem Projekt?
2. Variante: Learning-by-doing. Ich setze mich direkt an Tests für das Projekt ran und programmiere Tests und dann den Quellcode und hoffe, dass ich auf die richtigen Ideen komme?

Ich habe bereits die Forensuche, die F.A.Q. und Googel bemüht. Mir fehlt gerade die richtige Strategie, um die Hausarbeit nach Test-First zu programmieren. Ich habe mir bereits einiges durchgelesen (beispielsweise solche Artikel http://www.sybit-agile.de/blog/2012/03/keine-zeit-fuer-unit-tests-test-first/, aber irgendwie fehlt mir so der Aha-Effekt. Ich hoffe, mir kann hier jemand den richtigen Weg weisen. Ich habe vom Testing bisher nur ein grobes (wenn überhaupt vorhandenes) Verständnis.

 

[Saheeda]

Hi,

wenn du vom Testen kaum Ahnung hast, würde ich nicht direkt mit gemockten Tests einsteigen. Mocken ist das "Faken" von anderen Komponenten, um die eigentlichen Testklassen möglichst unabhängig testen zu können. Also z.B. "Angenommen, bei Anfrage x liefert die Datenbank Datensatz y. Wie reagiert mein Service?"

Für testgetriebene Entwicklung reicht auch JUnit. Das ist von der Einarbeitung her der geringste Aufwand.

Ich gehe dabei sehr kleinschrittig vor. Als ich z.B. das erste mal mit Datenbanken und SQL gearbeitet habe:
1. Besteht grundsätzlich eine Datenbankverbindung?
2. Ist meine einfache Select-Query korrekt?
3. Ist meine select query mit where-Klausel korrekt?
4. Ist die join-query richtig geschrieben?

Oder beim Taschenrechner:
1. Wird "1+1" richtig berechnet?
2. Wird "1+1/2" richtig berechnet?
3. Funktioniert "(1+2)/2+5" richtig?

Mit vielen Mini-Tests fällt es zumindest mir wesentlich einfacher, überhaupt irgendeinen Ansatz zu finden.

 

[stg]

Oder du programmierst einfach erst mal drauf los und schreibst die Test halt hinterher .... das ist natürlich kein sauberes Vorgehen, aber wenn die Zeit bei deiner Uni-Aufgabe drückt, dann muss man halt mal ein bisschen schummeln *hust*

 

[Kiel88]

Ich probiere es sonst erstmal mit JUnit und arbeite mich da ein.

Sofort drauf losprogrammieren und erst dann die Tests ist etwas doof. Wir müssen alles im Gitlab hochladen und jeder Schritt muss 100% nachvollziehbar und dokumentiert sein. Wenn, dann müsste ich erst den Quellcode schreiben, die Tests schreiben, und dann alles portionsweise (erst Tests, dann den Quellcode) an verschiedenen Tagen hochladen, da sonst alles mit Durchgefallen bewertet wird ;-)

 

[klauskarambulut]

Mockito braucht man nicht wenn man TDD macht. Das braucht man nur, wenn man mit legacy Code (Code ohne Tests) arbeitet.

Auf JUnit kann man theoretisch auch verzichten und sich was eigenes schreiben. Es ist aber so weit verbreitet, dass der Einsatz sinnvoll ist.

Das Ziel bei TDD ist nicht, dass man Code und Testcode hat und der Testcode bestättigt, dass der Code fehlerfrei wäre.
Das Ziel ist, dass der Code den man schreibt, jedes einzelne Stück (Unit), getestet werden kann.

Das Ziel ist schönen, wartbaren, modularen Code zu bekommen.

 

[Hans_G]

Als ich mich in JUnit einarbeiten wollte, habe ich eine Weile nach geeigneten Tutorials und Büchern umgeschaut. Vieles in dem Bereich hat viel Text und wenig Inhalt. Hilfreich fand ich das Buch "Pragmatic Unit Testing in Java 8 with JUnit": https://pragprog.com/book/utj2/pragmatic-unit-testing-in-java-8-with-junit
Statt sich erst seitenlang philosophisch über Tests auszulassen, lernt man gleich zu Anfang, wie man Test schreiben und sinnvoll einsetzen kann.