Unit Tests

[LeKuchen]

Hallo zusammen,

ich wollte mal wissen, ob Ihr für Eure Projekte auch standardmäßig Unit Tests durchführt. Nutzt Ihr JUnit, PhpUnit oder Nunit _wirklich_? Bei _allen_ Projekten?

Ja, ich weiß natürlich, dass das total sinnvoll ist, aber irgendwie muss ich noch davon überzeugt werden...;o)

Erstmal bedeutet es ja mehr Aufwand (was sich wahrscheinlich dann später bei der Fehlerbeseitigung dann wieder relativiert) und es verzögert imho den Programmierfluß.

Außderdem habe ich lieber termingerecht die Applikation draußen mit ein paar mehr Bugs als eine mit weniger Bugs aber ein paar Wochen später... (tjaja, der Termindruck: Der Termin, Tom DeMarco - lesenswert!)

Wie sind Eure Erfahrungen?
Gruss
LeKuchen

[entropie]

Hallo zusammen,

Hoi

ich wollte mal wissen, ob Ihr für Eure Projekte auch standardmäßig Unit Tests durchführt. Nutzt Ihr JUnit, PhpUnit oder Nunit _wirklich_? Bei _allen_ Projekten?

Auschliesslich.

Wie sind Eure Erfahrungen?

In meiner favourisierten sprache -- Ruby -- ist es ein fest unittests zu benutzen, normalerweise schreibe ich sogar zuerst die tests mit den erwartungen und anschliessend erst "wahren" code.

Mfg entropie

[Cheatah]

Hi,

ich wollte mal wissen, ob Ihr für Eure Projekte auch standardmäßig Unit Tests durchführt. Nutzt Ihr JUnit, PhpUnit oder Nunit _wirklich_? Bei _allen_ Projekten?

ja, selbstverständlich. Was allerdings nicht immer klappt[1], ist TDD im Sinne des Erfinders, also erst die Tests zu schreiben und dann die Unit.

Ja, ich weiß natürlich, dass das total sinnvoll ist, aber irgendwie muss ich noch davon überzeugt werden...;o)

Nein, Du musst gezwungen werden. Im Idealfall von Dir selbst. Es kostet etwas Überwindung, aber dann sieht man die Vorteile recht schnell.

Erstmal bedeutet es ja mehr Aufwand (was sich wahrscheinlich dann später bei der Fehlerbeseitigung dann wieder relativiert)

Absolut.

und es verzögert imho den Programmierfluß.

Absolut nicht. Es sei denn, unter Programmierfluss verstehst Du, den Code ständig zu modifizieren, weil Du Dir erst später darüber klar wirst, was Du eigentlich haben willst ;-)

Außderdem habe ich lieber termingerecht die Applikation draußen mit ein paar mehr Bugs als eine mit weniger Bugs aber ein paar Wochen später...

Ich habe lieber eine nachweislich bugfreie[2] termingerecht fertig, die dem Kundenwunsch entspricht. Ja, das geht. Kennst Du Scrum?

Cheatah

[1] Oft ist es gerade bei kleineren Dingen sinnvoll, sie einfach zu entwickeln. Wenn sie dann irgendwo eingesetzt werden, werden die Rahmenbedingungen in Form von Tests festgelegt.
[2] Im Sinne von UnitTests. Dass keine Software ohne Bugs ist steht fest - also muss man sich den Begriff richtig definieren ;-)

[LeKuchen]

Hallo,

Nein, Du musst gezwungen werden. Im Idealfall von Dir selbst. Es kostet etwas Überwindung, aber dann sieht man die Vorteile recht schnell.

Ich glaube das mit dem zwingen auch...;o)

Ich habe lieber eine nachweislich bugfreie[2] termingerecht fertig, die dem Kundenwunsch entspricht. Ja, das geht. Kennst Du Scrum?

Habe mich gerade über den Ansatz Scrum schlaugemacht. Gibt es da Tools, die bei der Umsetzung dieser Strategie helfen? Die Richtung XP stimmt ja schon, wenn ich Scrum richtig verstanden habe, ist dies ja noch eine Ergänzung....

Das Problem ist, das ich meine Kollegen natürlich auch überzeugen müsste, da der Einsatz nur durch mich nichts bringen würde. Da wir aber Klassen, Module etc häufig in verschiedenen Projekten wiederverwenden (und diese schon seit langem in der Praxis erprobt sind) ist es halt schwierig, sie von der Notwendigkeit von Unit Test zu überzeugen. Manchmal praktizieren wir auch Ansätze von Pair Programming was dann auch den Unit Test zunächst nach zusätzlichem Aufwand aussehen lässt....

Ich werde für mich es mal an einem kleinen Projekt übers Wochenende testn - mal sehen, was dabei rauskommt.

Gruss
LeKuchen

[Cheatah]

Hi,

Habe mich gerade über den Ansatz Scrum schlaugemacht. Gibt es da Tools, die bei der Umsetzung dieser Strategie helfen?

keine guten bisher. Aber: Wir arbeiten dran ;-)

Die Richtung XP stimmt ja schon, wenn ich Scrum richtig verstanden habe, ist dies ja noch eine Ergänzung....

Das kann man so sehen, wenn man möchte. Es gibt auf jeden Fall Aspekte, die man sowohl bei Scrum als auch bei XP findet.

Das Problem ist, das ich meine Kollegen natürlich auch überzeugen müsste, da der Einsatz nur durch mich nichts bringen würde.

Richtig, es braucht ein Team.

Da wir aber Klassen, Module etc häufig in verschiedenen Projekten wiederverwenden (und diese schon seit langem in der Praxis erprobt sind) ist es halt schwierig, sie von der Notwendigkeit von Unit Test zu überzeugen.

Wie bitte? Das ist doch _der_ Fall, in dem man Unit-Tests einsetzt! Wie will man ansonsten sicher stellen, dass die verwendeten Module bei einer Veränderung noch immer den Anforderungen genügen?

Betrachte diese Module und Klassen aus Sicht des jeweiligen Projekts als Fremd-Software. Schon müssen Annahmen über die explizite Funktionsweise getroffen werden. Diese Annahmen dokumentiert ihr in Form von Unit-Tests, und ihr habt jederzeit die Möglichkeit zu überprüfen, ob die Software funktioniert. Und erzähl mir jetzt bitte nicht, dass sich die Module nicht mehr verändern ;-)

Manchmal praktizieren wir auch Ansätze von Pair Programming was dann auch den Unit Test zunächst nach zusätzlichem Aufwand aussehen lässt....

Unit-Tests sehen eigentlich immer nach zusätzlichem Aufwand aus, sofern man sie nicht ganz am Anfang schreibt. Es ist wie mit dem Einsatz zusätzlicher Technologien auf einer Website: Man braucht keine Alternative zu Flash, sondern Flash _ist_ die Alternative. Es kommt halt auf die Denkweise an.

Ich werde für mich es mal an einem kleinen Projekt übers Wochenende testn - mal sehen, was dabei rauskommt.

Ich freue mich auf Deinen Erfahrungsbericht!

Cheatah