Moderne Softwareentwicklung

[p80286]

Zitat von UntoterGeist:

Und diese ganzen neuen Methoden sind ja schön. Aber in wiefern verbessern oder beschleunigen sie was?

Naja ich hab versucht mich mit dem "TestDriven" auseinander zu setzen. Letztlich geht es darum sich im Vorfeld darüber klar zu werden was schief gehen kann, und dementsprechend daran orientiert das eigentliche Programm zu schreiben.

Wie sagte mal ein Kollege vor ein paar Jahren "Nur Vollidioten glauben, daß alles so läuft wie der Programmierer es wünscht. Grundsätzlich mußt Du vom schlimmsten ausgehen und Dein Programm daran orientieren."

Der Spruch ist älter als Testdriven und OOP zusammen.

Gruß
K-H

[jfheins]

Moin

Zitat von p80286:

Zitat von UntoterGeist:

Und diese ganzen neuen Methoden sind ja schön. Aber in wiefern verbessern oder beschleunigen sie was?

Naja ich hab versucht mich mit dem "TestDriven" auseinander zu setzen. Letztlich geht es darum sich im Vorfeld darüber klar zu werden was schief gehen kann, und dementsprechend daran orientiert das eigentliche Programm zu schreiben.

Halte ich so für unrichtig.

Test driven sagt ja erstmal, dass die die Anforderungen die du bekommt erst in einen Test gießen sollst und dann umsetzen.
Ergebnis sollte ein Programm sein, dass die Business-Logik nicht nur gemäß den Anforderungen umsetzt, sondern dies (mehr oder weniger beweisbar) tut. Alle Tests grün = alle Anforderungen erfüllt.

Der Benefit ist nun, dass du nach Änderungen (Refactorings, Features, Bugfixes) die Tests laufen lassen kannst und relativ sicher sein kannst, dass die keine neuen Bugs erzeugt hast. Wenn doch, dann war das entweder eine Spezifikationslücke (und deshalb gab es keinen Test) oder der Test hat die Spec nicht ausreichend abgedeckt.

Was natürlich nicht passieren darf ist "ich ändere das mal so und so, um dem Bug zu fixen, und dann schau ich welche Tests kaputt sind um die dann auch anzupassen" - das ist sinnfrei und kein TDD.

[p80286]

Zitat von jfheins:

Was natürlich nicht passieren darf ist "ich ändere das mal so und so, um dem Bug zu fixen, und dann schau ich welche Tests kaputt sind um die dann auch anzupassen" - das ist sinnfrei und kein TDD.

Nun, gerade um solche cleveren Lösungen zu unterbinden werden wohl Methoden wie TDD propagiert. Das diese dann vom Hilfsmitel zur Quasireligion mutieren nunja.....

Gruß
K-H

[Uwe Raabe]

Zitat von p80286:

Nun, gerade um solche cleveren Lösungen zu unterbinden werden wohl Methoden wie TDD propagiert. Das diese dann vom Hilfsmitel zur Quasireligion mutieren nunja.....

Vielleicht braucht es bei TDD ähnlich wie bei der Religion auch sowas wie einen Moment der Erleuchtung. Genauso wird es auch bei TDD wohl niemanden geben der gänzlich frei von Sünde ist.

[dummzeuch]

Zitat von jfheins:

Was natürlich nicht passieren darf ist "ich ändere das mal so und so, um dem Bug zu fixen, und dann schau ich welche Tests kaputt sind um die dann auch anzupassen" - das ist sinnfrei und kein TDD.

Auch das kann legitim sein, wenn sich z.B. herausstellt, dass die Tests nicht korrekt die Anforderung wiedergaben oder selbst fehlerhaft waren. Tests sind schließlich auch nur Code und der kann Bugs enthalten.

[Uwe Raabe]

Zitat von dummzeuch:

Auch das kann legitim sein, wenn sich z.B. herausstellt, dass die Tests nicht korrekt die Anforderung wiedergaben oder selbst fehlerhaft waren. Tests sind schließlich auch nur Code und der kann Bugs enthalten.

In dem Fall würde man aber erst die Tests korrigieren und danach, wenn die dann fehlschlagen, den eigentlichen Code.

Leider fallen viele Anwender von TDD in die Rot-Grün-Falle: Der Code wird solange angepasst, bis alle Tests grün sind. Dann geht es schon weiter zum nächsten Bug/Feature/Test. Der TDD-Zyklus ist damit aber noch gar nicht abgeschlossen, denn er besteht aus drei Schritten: write the test - write code to make the test green - refactor the code to make it clean. Der letzte Schritt wird leider viel zu oft übersprungen, da er leider sehr zeit-intensiv ist und einen guten Überblick über das Gesamtprojekt erfordert. Übrigens: Das Postulat schreibe nie mehr Code als nötig ist, um den Test grün zu machen ist hierzu kein Widerspruch. Wir schreiben ja nicht mehr Code, sondern ändern lediglich den vorhandenen. Dabei nutzen wir den grünen Test als Hinweis, daß wir beim Refactoring nichts kaputt gemacht haben.

[dummzeuch]

Zitat von Uwe Raabe:

Zitat von dummzeuch:

Auch das kann legitim sein, wenn sich z.B. herausstellt, dass die Tests nicht korrekt die Anforderung wiedergaben oder selbst fehlerhaft waren. Tests sind schließlich auch nur Code und der kann Bugs enthalten.

In dem Fall würde man aber erst die Tests korrigieren und danach, wenn die dann fehlschlagen, den eigentlichen Code.

Was voraussetzt, dass man weiß, dass die Tests fehlerhaft sind. Wenn man das aber erst sieht, weil sie nach einer Änderung am Code fehlschlagen, dann kann man sie auch erst dann anpassen.

[freimatz]

Äh, Nein.
Wenn man einen Code zu ändern hat, dann sucht man bei TDD erst den dazugehörigen Test und ändert dann erst den. Und danach dann den produktiven Code.

[Uwe Raabe]

Zitat von freimatz:

Äh, Nein.
Wenn man einen Code zu ändern hat, dann sucht man bei TDD erst den dazugehörigen Test und ändert dann erst den. Und danach dann den produktiven Code.

Nein, eben nicht! Es ist auch bei TDD nicht nur üblich, sondern auch erwünscht, daß der Code geändert wird. Der Test ist ja gerade dazu da, daß man diese Änderung durchführen kann, ohne die Funktionalität des Codes zu verändern. Nirgendwo steht, daß man den Code nicht mehr ändern darf, sobald der Test auf grün steht. Das wäre genau das Gegenteil von dem, was man mit TDD erreichen will.

In dem Zusammenhang kann es auch vorkommen, daß ein Test verworfen, ersetzt oder verändert wird - z.B. weil er fehlerhaft ist.