Projektvorstellung: Wait Game

[andy_m4]

Nein, du sollst Tests für die Anforderungen schreiben...

Achso. Sag das doch gleich. :-)

 

[playerthreeone]

Nein, du sollst Tests für die Anforderungen schreiben...

Und wer testet die Tests?
Wie gesagt: Tests sind richtig und wichtig. Aber TDD als "Allheilmittel" sicher nicht.

 

[Ganymoe]

Dann haben wir gemerkt das wir auch hier aufpassen müssen das der vollumfänglich genug ist. Also Schreiben wir jetzt Anforderungen für die Tests und hoffen das wir bei den Anforderungen dann auch alles richtig gemacht haben oder sollen wir vor den Anforderungen noch ne Spezifikation setzen? Oder was kommt dann da vor? und davor? Und davor?

Wenn alle Methoden knackig kurz sind, und diese auch nur jeweils eine sache machen, sollt sich das mit den Anforderungen für Unittests in Grenzen halten.

Aber wie schon gesagt:

• wenn ich was programmiere, weiss ich ja (hoffentlich) was ich machen will. Ich nehm mir was vor und implementiere das. Obs dazu ein ticket gibt, einen Schmierzettel oder nur ein Hirngespinst. ist egal.
• Ich werde dieses feature ja in einer Klasse aufrufen.
• dann schreib ich den Test in der Testklasse für diesen Aufruf. Sei es eine simple Berechnung oder ein Aufruf einer gemockten Klasse
• dann implementiere ich gegen den Test
• dann überleg ich mir weitere Tests z.b. was soll im Fehlerfall passieren etc..
• falls gemockt wurde beginnt das ganze von vorne für diesen aufruf. und das spiel wiederholt sich.

Sicher kommt es auf das Projekt drauf an, aber ich bin mir sicher im Ganzen ist man schneller als alles manuell zu testen und immer das simple Programm, einen Server oder Spiel zu starten, und alle Voraussetzungen zu schaffen um überhaupt zu dieser Methode zu kommen und diese (vielleicht nur einmalig testen zu können, weils kracht).