ich habe noch mal ein bisschen weiter in die Materie reingelesen. Das Thema lässt mich nicht los und ich glaube mittlerweile, dass ich

1. Zu viel mit Unit Test machen wollte.
2. Da Aspekte von anderen “Testarten” (Funktionale Tests die zum Beispiel mit Selenium gemacht werden können) reingemischt habe.

Ich werde einfach mal anfangen ein bisschen auszuprobieren, ob und wie ich vielleicht noch ein paar sinnvolle Tests für meine Applikation bauen kann, damit ich besser für die Zukunft gerüstet bin.

Das Thema ist echt spannend.

sorry mal wieder für die späte Antwort, aber ich musste angestrent die Woche arbeiten… ;)

@TDD
Ich finde toll dass du es im Studium gelernt bzw. zumindest angeschnitten hast. Bei uns kam das leider gar nicht vor. :( Ich habe diese Woche aber selbst damit zu kämpfen gehabt, eine sinnvolle Testumgebung für ein Mini-Projekt aufzusetzen. Da stellt sich natürlich immer die Frage von Aufwand/Kosten Nutzen. Ich habe die Testumgebung sehr klein gehalten, aber für dieses Projekt war es noch ok.

Ich bin aber der Meinung sobald mehr als zwei Leute an einem Projekt arbeiten, geht quasi kein Weg daran vorbei. Denn jemand der etwas selber programmiert hat soviel Insider-Wissen, dass kann man gar nicht vermitteln. Bei xUnit-Tests fällt aber eine Änderung im Rückgabetyp bzw. in der Signatur immer auf. Es wird eben klar gekapselt und diese Kapselung wird unabhängig davon noch einmal getestet.

@Loose-Coupling
Loose-Coupling definiert nicht nur dass Sub-Systeme nur über Schnittschnellen sprechen dürfen sondern es definiert auch, dass Sub-Systeme so wenig wie möglich miteinander kommunizieren sollen. Ein guter Einstieg ins Thema ist hierbei natürlich wieder Wiki (http://en.wikipedia.org/wiki/Loose_coupling). Aber auch die GoF haben immer wieder darauf hingewiesen. Und imo ist dieser Punkt Punkt um ein Vielfaches schwieriger umzusetzen als ein xUnit-Test-Setup. Ich kann beides nicht. :( ;)

@Sonstiges
Den Chef und die Firma kann ich dir gerne sagen, aber das bitte lieber per E-Mail. Ich glaube du solltest als Moderator Zugriff auf meine E-Mail haben. Wenn es dich also interessiert. Hetzer- bzw. Herzereien haben nichts in der Öffentlichkeit verloren. ;)

Viele Grüße und ein schönes Wochenende
Ulf

Danke für die schnelle Antwort!
Ich schreibe meine Funktionen oft neu und ändere die codes “minütlich”:-P
Also werde ich mich wohl mal etwas eingehender mit xUnit auseinandersetzen!

Das es keinen Königsweg gibt war mir auch schon vorher bewußt , ich wollte nur mal schauen was ihr für erfahrungen gemacht habt, wollte hören womit ihr am besten klar kommt!

Nun ja wie gesagt - Du hast mir auf jeden fall geholfen , ich hoffe das bei weiteren fragen genau so schnell geantwortet wird. Daumen hoch!

Lg, Flug

wie du der Diskussion entnehmen kannst, ist das schwierig. Der Königsweg ist natürlich, dass man beides hat. xUnit + Frontend.

Meine Meinung ist, dass du das testen solltest, was für dich wichtiger ist, in meinem Fall ist es das, was der Kunde sieht und benutzt und was “funktionieren” muss. Wenn ich einen Anruf bekomme, dass etwas nicht funktioniert, dann will ich die Tests laufen lassen können, um zu sagen: Das Problem ist nicht die Seite, sondern xyz.

Aber die Jungs vom Test-Driven-Development haben schon recht, dass wenn du oft deine Funktionen neu schreibst, oder Code änderst, oder viele Leute an dem Projekt gleichzeitig arbeiten, dann würde ich auf jeden Fall xUnit vorziehen.

Hoffe das hilft?

Gruß
Philipp

Die App habe ich angefangen, bevor ich im Studium all die tollen Sachen über TTD gehört habe (was immer noch nicht genug war, um es für mich so verständlich zu machen, dass ich weiß was ich tun müsste), aber das Dilemma versuche ich ja gerade zu beheben und wahrscheinlich hast du recht, ich muss einfach mehr ausprobieren, anstatt das Problem schon mal im Kopf lösen zu wollen, vielleicht lösen sich meine Fragen dann ganz von alleine.

Zum Loose-Coupling ist noch zu sagen, dass man damit ja nicht meint, dass ein Objekt niemals eine Funktion in einem anderen Objekt aufrufen darf, sondern nur, dass diese Aufrufe über schön definierte Interfaces stattfinden, so dass man nicht merkt, wenn man in dem aufgerufenen Objekt etwas ändert, bzw. das aufrufende Objekt nicht ebenfalls ändern muss. Und das ist bei mir soweit der Fall.

Schlechtes Software-Design ist da etwas schwammig. Für den Anwendungsfall, für den die Applikation ist (CMS, 1 Developer, Kudenprobleme lösen) ist das Software-Design mehr als optimal, für den Anwendungsfall TTD kann ich dir die Frage eben nicht beantworten, aber ich würde sagen, dass ich da vielleicht Defizite aufweise ;)

P.S: Herzlichen Glückwunsch, wenn dein Chef TTD ausgibt, dann wüßte ich zu gerne wo du arbeitest. Weil da wo ich früher gearbeitet habe, da war es nur sehr schwer von unten zu vermitteln, wofür Software Design gut sein soll (da wusste ich ja noch nichts von TTD, hätte aber wenigstens gerne eine sinnvolle Planung gemacht) und wer das bezahlen soll, also musste ich das so lala nebenher machen! :)

Plädoyer mit kurzer Einführung in das Testframework “Selenium”. Selenium ist in der Basisversion ein Firefox-Plugin, mit dem man Makros aufzeichnen kann….

es ist zwar schon ein paar Tage her, aber ich hoffe du bist noch immer wissbegierig… ;)

@Test-Driven-Development
Du hast es schon richtig bemerkt, du wirst niemals alle deine einzelnen Units auf alle Zustände und Möglichkeiten testen können. Wenn dir es aber gelingt, deine Units auf die wichtigsten und bedeutesten Zustände zu testen, dann hast du schon etwas erreicht. Denn in diesem Fall hast du für diese Anwendungsfälle Test-Sicherheit. Was wichtig und bedeutend ist, definierst im übrigen du selbst. Da du den Test vor der eigentlichen Implementierung der Unit schreiben sollst, machst du dir darüber zwangsläufig Gedanken, was bedeutsam für deine Anwendung ist. Man wird mit Testen niemals 100%-ige Fehlerfreiheit erreichen, aber doch bedeutend mehr als ohne (vor allem bei größeren Software-Projekten).

@Testen von ineinander abhängigen Klassen
Da solltest man sich grundsätzlich hinterfragen ob das Software-Design an dieser Stelle richtig ist. Große Abhängigkeiten zwischen Klassen widersprechen ja dem Prinzip des “loose coupling”. Wenn diese Abhängigkeiten aber bestehen müssen, dann gibt es über setup und reset-Methoden sowie Mock-Objeckts durchaus die Möglichkeit dies zu testen. Es erhöht nur den Testaufwand - der Preis für schlechtes Software-Design.

Ich hoffe dir damit etwas geholfen zu haben. Im übrigen darfst du nicht frustieren. Ich habe mich am Anfang auch gefragt wieso es Test-Driven-Development gibt und bin daran teilweise fast verzweifelt. Viel Geduld, viel Probierei und viele Diskussionen mit meinem Chef haben mich von der Notwendigkeit überzeugt. Und jetzt bin ich selber Verfechter davon, man sieht es ja! ;)

Viele Grüße aus Berlin
Ulf