Designfrage - komplexe vs. flache Klassenhierarchie

[deetee]

Unit Testing hat Schwächen, allerdings ist es kein Vergleich zur Entwicklung ohne Unit Tests. So wie es fahrlässig ist ohne Gurt zu fahren, ist es auch fahrlässig ohne Unit Tests zu entwickeln. Auch das Fahren mit Gurt hat Nachteile, trotzdem weiß man im Profirennsport den Gurt zu schätzen. Genauso wie ein profesioneller Entwickler Unit Testing zu schätzen weiß.

Ich sag ja nix gegen (halb)automatisierte Unittests (setze sie ja selber gerne ein), bin mir aber ihrer Schwächen bewusst.

Bernd

Aber wohl nicht ihrer Stärken...

 

[Sym]

Kann natürlich auch bedeuten, dass das Risikobewusstsein schrumpft nach dem Motto "der Unittest wird schon meckern wenn ich was vergurkt habe".

Bernd

Das ist quatsch.

 

[Bernd Hohmann]

Ja nee, am besten also nur Blind Proggen und dann ausliefern, weil Tests schlecht fürs Qualitätsbewusstsein sind? :joke:

Ich habe eine geringe Fehlerquote bei Auslieferung - ich glaube nicht dass das ohne eine sorgfältige QA wärend der Entwicklung machbar ist. Und unter QA verstehe ich schon etwas mehr, als auf alten Code automatisierte Tests loszulassen nur weil Grün so beruhigend ist

Aber kaufmännische Programmierung mit seinen vielen Eingaben ist eh so ein Sonderfall, andere Branchen lassen sich bestimmt besser automatisch testen.

Bernd

 

[deetee]

Aber kaufmännische Programmierung mit seinen vielen Eingaben ist eh so ein Sonderfall, andere Branchen lassen sich bestimmt besser automatisch testen.

Bernd

Ja, so wird es sein

 

[maki]

Ich habe eine geringe Fehlerquote bei Auslieferung - ich glaube nicht dass das ohne eine sorgfältige QA wärend der Entwicklung machbar ist. Und unter QA verstehe ich schon etwas mehr, als auf alten Code automatisierte Tests loszulassen nur weil Grün so beruhigend ist

Die Qualität der Tests entscheidet ob "grün" aussagekräftig ist oder nicht.

Aber kaufmännische Programmierung mit seinen vielen Eingaben ist eh so ein Sonderfall, andere Branchen lassen sich bestimmt besser automatisch testen.

Sehe da kein Problem, weder für Unittests noch für Integrationstests.
Ist IMHO alles eine Frage der Struktur, sowhl des Codes, als auch der Tests.

Der Punkt ist doch der:
Jeder Entwickler testet, autom. Tests haben Vorteile.

Automatische Integrationstests sind in der Entwicklung erstmal aufwändig, isolierte Unittests nicht, wenn die Strukturen es zulassen, bei SW die testgetrieben geschrieben wurde, hat der Code immer die passende Struktur, geht ja gar nicht anders.

Wenn man natürlich versucht einen isolierten Unittest zu schreiben nachdem der ProdCode schon "fertig" ist, kann es sehr schwer und aufwändig werden.

Tests für bestehenden Code zu schreiben ist am schwierigsten, viele Entwickler tappen in diese Falle und haben danach eine Abneigung gegen Unittests.
Speziell die Wartbarkeit von autom. Unittests zeigt einem recht schnell ob die Struktur/Tests passen, ober eben nicht.

Zum Thema zahlen:
Wenn ein "normaler" Entwickler mehr als 10-15% der Zeit isol. Unittests braucht die er braucht um den Prod. Code zu schrieben, dann ist was falsch.
Ja, klingt erstmal extrem, soll aber deutlich machen das isol. Unittests meist falsch geschrieben werden, meist weil die Strukturen es nicht besser zulassen.

Mit "normaler" Entwickler meine ich damit den Entwickler, der bestehende Test- APIs/Utils/Frameworks nutzt um seine Tests zu schreiben, dass irgendwer diese Test- APIs/Utils/Frameworks schreiben muss ist klar.

Was mit schlechtwartbaren Test passiert wissen wir ja alle:
Dieser Klotz am Bein wird irgendwann weggeworfen...

 

[Bernd Hohmann]

Die Qualität der Tests entscheidet ob "grün" aussagekräftig ist oder nicht.

Du hast meinen milden Spott nicht durchschaut: Wenn ich per Modul 10 Tests habe und 100 Module habe werden 1000 Tests durchgeführt. Falle ich durch einen Test durch, habe ich immer noch eine saugute Fehlerquote von 1 Promille die ich nach oben reporten kann.

[...] bei SW die testgetrieben geschrieben wurde, hat der Code immer die passende Struktur, geht ja gar nicht anders.

Ja, "test driven".. da will ich mich mal dran versuchen. Aber mein aktuelles Java-Hobby-Projekt ist 99% GUI da fehlt es im Moment noch an allem. Mache dazu gelegentlich mal ein Thema auf.

Tests für bestehenden Code zu schreiben ist am schwierigsten, viele Entwickler tappen in diese Falle und haben danach eine Abneigung gegen Unittests.

Das mag auch daran liegen, dass der bestehende Code auf andere Testverfahren ausgelegt ist. Es ist ja nicht so, dass automatisierte Unittests (im Sinne von zb. JUnit) die einzigen Verfahren sind. Lohn&Gehalt hab ich früher so getestet dass es einen entsprechenden Datenbestand gab und ein großes Tastaturmacro wärend der Mittagspause alle Abrechnungen über einen definierten Datenbestand ausgeführt hat. Danach die Ausdrucke prüfen (goto 1)

Speziell die Wartbarkeit von autom. Unittests zeigt einem recht schnell ob die Struktur/Tests passen, ober eben nicht.

Wenn ein "normaler" Entwickler mehr als 10-15% der Zeit isol. Unittests braucht die er braucht um den Prod. Code zu schrieben, dann ist was falsch.

Das verstehe ich jetzt nicht. Meinst Du Gesamtaufwand = 100%, 10%-15% für Unittests, Rest für Produktivsystem? 10-15% erscheint mir etwas wenig. Gib mal ein ungefähres Beispiel was da getestet wird.

So.. jetzt mal die Bedienungsanleitung der neuen Küche lesen. Vielleicht finde ich die Taste um dieses dämliche Piepen abzuschalten :autsch:

Bernd

 

[deetee]

Du hast meinen milden Spott nicht durchschaut: Wenn ich per Modul 10 Tests habe und 100 Module habe werden 1000 Tests durchgeführt. Falle ich durch einen Test durch, habe ich immer noch eine saugute Fehlerquote von 1 Promille die ich nach oben reporten kann.

Mit Testdurchführungen (nicht nur Unit Tests) kann man lediglich die Existenz von Fehlern beweisen, niemals die Nicht-Existenz.
Wenn du also deinem Chef erzählst, dass du nur 1 Fehler in deinem Programm hast, dann ist das...ich sag mal sehr optimistisch gedacht.

Das was du durch rote unit tests reporten kannst sind die bekannten Fehler. Unit Tests und Integrationstests helfen dir nach einer Änderung (Bugfix, Refactoring, Change Request) die Sicherheit/Gewissheit zu haben, dass durch deine Änderung keine kritischen Seiteneffekte entstanden sind. Ohne solche Tests wäre so eine Aussage viel zu teuer, weil man erstmal alles manuell testen müsste.

Außerdem ist nicht die Anzahl der Tests alleine wichtig, sondern auch die Code Coverage. Unit Testing ohne Code Coverage Analyse macht überhaupt keinen Sinn. Wenn es also blöd läuft fragt dich deine QA oder Führungskraft, warum denn da noch soviele rote Zeilen markiert sind.

Und der eigentliche Gewinn durch solche autom. Tests und einer hohen Testabdeckung ist der, dass sie jeder zur Verfügung hat. Ein neuer Entwickler kann einen ersten Beitrag zum Projekt leisten und man hat schon mal eine erste Gewissheit, dass seine Arbeit ok ist, wenn alle Tests weiterhin durchlaufen. Das spart Zeit und Geld. Ein Entwickler ist schneller produktiv einsetzbar und seine Arbeit kann effizienter kontrolliert werden. Nicht selten benötigen Entwickler weitaus weniger Einarbeitungszeit, wenn Unit Tests und Integrationstest existieren. Schließlich zählt das auch zur Code Dokumentation.

 

[maki]

Du hast meinen milden Spott nicht durchschaut: Wenn ich per Modul 10 Tests habe und 100 Module habe werden 1000 Tests durchgeführt. Falle ich durch einen Test durch, habe ich immer noch eine saugute Fehlerquote von 1 Promille die ich nach oben reporten kann.

Ach, wenn es nur um das reporten geht kann man sehr einfach an den Zahlen drehen.
These: Man kann zB. 100% Coverage durch die Tests haben, ohne eine einzige Assertion/Expectation

Ja, "test driven".. da will ich mich mal dran versuchen. Aber mein aktuelles Java-Hobby-Projekt ist 99% GUI da fehlt es im Moment noch an allem. Mache dazu gelegentlich mal ein Thema auf.

GUI & isol. Unittests ist so eine Sache, TDD is da sehr schwer, aber MVP/Passive View/Presenter First bieten eine einfacher zu testende Struktur, verglichen zB. mit "MVC".
Würde dir nicht empfehlen TDD an einem prod. Projekt oder GUI auszuprobieren, Spiel-Projekte (zB. nur die Domäne einer Zeiterfassung mit TDD zu erstellen, ohne GUI etc. pp.) eignen sich IMHO am besten um was ganz neues zu lernen.

Das größte Schwierigkeit an TDD IMHO: Den eigenen Schweinehund überwinden
Die Gewohnheit Dinge auf eine bestimmte Art anzugehen muss erstmal überwunden werden...

Das mag auch daran liegen, dass der bestehende Code auf andere Testverfahren ausgelegt ist. Es ist ja nicht so, dass automatisierte Unittests (im Sinne von zb. JUnit) die einzigen Verfahren sind. Lohn&Gehalt hab ich früher so getestet dass es einen entsprechenden Datenbestand gab und ein großes Tastaturmacro wärend der Mittagspause alle Abrechnungen über einen definierten Datenbestand ausgeführt hat. Danach die Ausdrucke prüfen (goto 1)

"Halbautomatische" Tests sind manchmal zwingend notwendig, je nachdem was getestet wird (zB. das Layout), aber wenn sich etwas automatisieren lässt ist das ja eine Gute Sache

Das verstehe ich jetzt nicht. Meinst Du Gesamtaufwand = 100%, 10%-15% für Unittests, Rest für Produktivsystem? 10-15% erscheint mir etwas wenig. Gib mal ein ungefähres Beispiel was da getestet wird.

So war das gemeint.. wenn auch ein bisschen überspitzt ausgedrückt
Isolierte Unittests sind bei TDD Whitebox tests, d.h. der Test kennt über den inneren Aufbau der zu testenden Klasse und prüft eben "ob der Code so funktioniert wie er sollte", also das verhalten, nicht nur das Ergebnis.
Mit "isoliert" ist gemeint dass man wirklich nur eine Klasse bzw. Methode prüft, alles andere (bis auf die Java API) wird gemockt, die Mocks prüfen dann ob bestimmte Methoden aufgerufen wurden.

Mocks Aren't Stubs

Dadurch dass man "sehr wenig" Code pro einzelnem Test prüft (kurze Klassen & Methoden!), bleiben die Tests recht einfach und man vermeidet vielleicht einfacher das redundante abdecken von Prod Code durch verschiedene Tests und hat eine bessere "defect localisation".
Selbst dafür sind 10-15% der Zeit wenig und als Ziel gedacht, Anfangs 30% zu brauchen oder mehr ist üblich, man muss sich ja erst die Frameworks zusammensuchen und ein paar utils etc. bauen.. wichtig ist eben dass die Tests wartbar bleiben, den Änderungen am Prod. Code sollten Tests brechen, diese müssen "einfach" zu reparieren sein.
Ständiges refactoring gehört natürlich auch dazu, werden aber nicht in die "10-15%" reingerechnet

Unittests prüfen natürlich nicht ob das Gesamtsystem funktioniert
Integrationstests wie zB. End to End Tests etc. sind immer noch wichtig.
Für Integrationstests zB. kann man DBUnit nutzen um Daten in die DB zu klopfen bzw. zu prüfen.

 

[JohannisderKaeufer]

So.. jetzt mal die Bedienungsanleitung der neuen Küche lesen. Vielleicht finde ich die Taste um dieses dämliche Piepen abzuschalten :autsch:
Bernd

[OT]
Wenn ich das meine was es ist, dann kannst du dass per Mobiltelefon steuern.
Einfach 1 1 2 und Anruftaste tippen.
Dann per Sprachsteuerung weiter
- Rauchmelder piept
- Küche brennt
- ADRESSE angeben

15 Minuten warten und dann kommt ein Servicetechniker der das erledigt.

Hier ein Video zur besseren Veranschaulichung
The IT Crowd - Series 1 - Episode 2: Fire! - YouTube
[/OT]

 

[Bernd Hohmann]

Wenn ich das meine was es ist, dann kannst du dass per Mobiltelefon steuern.

Es war der Alarmpiepser des Kühlschranks weil die Temparatur noch > 10° war :toll:

Spülmaschine ist jetzt eingestellt, die zeigt per Projektor auf dem Boden an was sie gerade macht und wie lange es noch dauert.

Der Backofen wäre was für unseren Kollegen FArt: das Ding stellt eine riesen API in Form eines riesen Menues und einer 48seitigigen Bedienungsanleitung zur Verfügung. Der Unterschied zwischen "Dampfgaren, Intervalldampfaren, Biodampfgaren, feuchte Heissluft und heisse Feuchtluft" wird allerdings nirgends erklärt. Hätte ich die Firmware selber programmiert wüsste ich jetzt wenigstens was da abläuft. Hm... Vielleicht mal schauen was da für eine CPU drin? :idea:

Bernd

 

[Bernd Hohmann]

Und der eigentliche Gewinn durch solche autom. Tests und einer hohen Testabdeckung ist der, dass sie jeder zur Verfügung hat. Ein neuer Entwickler kann einen ersten Beitrag zum Projekt leisten und man hat schon mal eine erste Gewissheit, dass seine Arbeit ok ist, wenn alle Tests weiterhin durchlaufen. Das spart Zeit und Geld. Ein Entwickler ist schneller produktiv einsetzbar und seine Arbeit kann effizienter kontrolliert werden. Nicht selten benötigen Entwickler weitaus weniger Einarbeitungszeit, wenn Unit Tests und Integrationstest existieren.

Ich bekomme da ein gedankliches Problem bei großen Anwendungen.

Wenn in einem Produktivsystem massiv Refactoring bzw. Aufräumarbeiten betrieben werden sind Unittests prima, blöderweise ändern sich auch die ganzen Schnittstellen und Testvoraussetzungen sodass man diejenigen Entwickler in die Änderung der Tests stecken muss welche mit dem Gesamtsystem am besten vertraut sind.

Umgekehrt könnte man jetzt sagen: würden die fähigsten Entwickler die Änderungen selber durchführen statt Tests zur Überwachung der weniger fähigen Entwickler zu schreiben wäre man fertig (natürlich unter der Voraussetzung, dass die fähigen Entwickler sich selber eine Testsuite bauen um ihr Ergebnis zu überprüfen - diese Testsuite fällt aber wesentlich knapper aus als ein vollkommener Test).

Schauen wir mal, was bei Programmerweiterungen passiert...

Eigentlich das gleiche Problem: Um einen unerfahrenen Entwickler an die Sache heranlassen zu können, müssen erst die Tests aufgebohrt werden. Das können aber nur diejenigen Entwickler, die wissen wo wie was geändert werden muss und welche Fallstricke sich daraus ergeben. Ergo könnten die das auch gleich selber ordentlich machen.

Da kommen wir schnell zum Computer-Inder, nämlich die Umgebung so vorzubereiten dass auch der Kollege "irgendwo draussen" nichts falsch machen kann - mit dem Overhead, dass sich die kompetenten Leute darum kümmern müssen.

Naja - auf der anderen Seite: in der heutigen Zeit gibt es kaum Entwickler die sich ordentlich einarbeiten wollen/können weil die Projekte zu kurzfristig angelegt sind. Vielleicht ist das übliche "Fire & Hire"-Geschäft die Keimzelle für das überbordende Testen statt alle Kraft in die Weiterenticklung zu stecken.

Meine 5ct.

Bernd

 

[Sym]

Ich glaube, wenn Du so argumentierst, dann bekommt ihr nie neue Entwickler ins Boot, oder?

Die Probleme, die Du beschrieben hast, hat man doch auch ohne Unit-Tests. Der Vorteil bei Unit-Tests ist ja ebenfalls, dass solche Tests die Funktionalität dokumentieren. Sprich, wenn eine neue Person im Projekt den Code anfasst und dazu einen Test findet, weiß sie ungefähr, was bisher dort passieren sollte. Dementsprechend kann der Test auch von unerfahrenen Entwicklern angepasst werden. Ohne den Test hätte die Person auf jeden Fall weniger Wissen, oder nicht?

Und natürlich sind größere Refactorings nicht unbedingt etwas für Frischlinge.

Ich finde übrigens, dass Unit-Tests zu einem ordentlichen Arbeiten dazu gehören. Sie dokumentieren, wie das Verhalten von Methoden sein soll. Sie stellen sicher, dass sich das erwartete Verhalten auch nach Änderungen nicht ändert. Und wenn man die Tests bei Bugs immer schön nachzieht, erhöht dies immens die Stabilität der Software, weil mit großer Wahrscheinlichkeit dieser Defekt nicht wieder auftritt.

 

[deetee]

Wenn in einem Produktivsystem massiv Refactoring bzw. Aufräumarbeiten betrieben werden sind Unittests prima, blöderweise ändern sich auch die ganzen Schnittstellen und Testvoraussetzungen sodass man diejenigen Entwickler in die Änderung der Tests stecken muss welche mit dem Gesamtsystem am besten vertraut sind.

Bei einem Refactoring ändern sich selten Schnittstellen, vorallem keine öffentlichen. Auch die Testvoraussetzungen bleiben die selben, weil ja das Ziel von Refactoring keine neue Funktionaliät ist, sondern das Programm soll nachher genauso funktionieren, wie es vor dem Refactoring lief.

Umgekehrt könnte man jetzt sagen: würden die fähigsten Entwickler die Änderungen selber durchführen statt Tests zur Überwachung der weniger fähigen Entwickler zu schreiben wäre man fertig (natürlich unter der Voraussetzung, dass die fähigen Entwickler sich selber eine Testsuite bauen um ihr Ergebnis zu überprüfen - diese Testsuite fällt aber wesentlich knapper aus als ein vollkommener Test).

Da hast du mich falsch verstanden oder ich mich falsch ausgedrückt, denn man schreibt niemals Tests, um andere Entwickler besser überwachen zu können, sondern zwecks Wartbarkeit und Änderbarkeit. Natürlich auch wegen weiteren Gründen, aber Wartung und Anpassung werden i.d.R. auch von anderen Entwicklern übernommen, als derjenige der es entwickelt hat. Und Unit/Integrationstests helfen dabei sehr...wenn man sich damit auskennt. Das ist eigentlich auch der größte Nachteil den ich an Unit Testing bzw. Testen mit einem Unit Test Framework sehe, es ist eine eigenständige Disziplin und muss erlernt werden, um wirklich effizient zu sein.
Das was du jetzt mit "Testsuite der fähigen Entwickler" bezeichnest, sollten IMHO die Unit- und Integrationstests sein, denn genau das ist es, was ich von fähigen Entwickler heutzutage erwarte.
Was du unter einem "vollkommenen Test" verstehst, weiß ich nicht, scheint mir aber nichts mit Unit Testing zu tun zu haben.

Eigentlich das gleiche Problem: Um einen unerfahrenen Entwickler an die Sache heranlassen zu können, müssen erst die Tests aufgebohrt werden. Das können aber nur diejenigen Entwickler, die wissen wo wie was geändert werden muss und welche Fallstricke sich daraus ergeben. Ergo könnten die das auch gleich selber ordentlich machen.

Selber machen setzt voraus, dass der Entwickler auch noch zur Verfügung steht, also noch im Unternhemen sein muss und auch für die Änderung zeitlich abgestellt werden kann.
Das "Aufbohren" von Tests kann durchaus notwendig werden. Aber warum traust du das nur den Entwicklern zu, die die Tests geschrieben haben? Anders gesagt, wenn die Entwickler schon vorher ordentlich geabeitet haben, dann sollten es andere Entwickler auch leichter haben ordentlich weiter zu entwickeln.
Natürlich muss man die Anforderungen kennen, damit der Test auch nach der Änderung noch genau das macht, was er machen soll. Das bedeutet nichts anderes als Einarbeitung. Es kann schließlich nicht im Sinne der Firma sein, dass Programme an bestimmte Entwickler gebunden sind. Das mag für dne Entwickler toll sein, ich finde so eine Einstellung mehr als gefährlich und zeugt von wenig Qualitätsbewusstsein und Kundenorientierung.

Naja - auf der anderen Seite: in der heutigen Zeit gibt es kaum Entwickler die sich ordentlich einarbeiten wollen/können weil die Projekte zu kurzfristig angelegt sind. Vielleicht ist das übliche "Fire & Hire"-Geschäft die Keimzelle für das überbordende Testen statt alle Kraft in die Weiterenticklung zu stecken.

Da ist auf jedenfall was dran. Die Budgets und Deadlines geben oft nicht den Raum für große qualitätsfördernde Maßnahmen. Deswegen ist es so wichtig, dass Entwickler in der selben Zeit besseren Code schreiben lernen. Unit Testing ist dafür ein guter Weg, allerdings benötigt man einige Jahre um wirklich auf ein gutes Niveau zu kommen. Ich beschäftige mich seit gut 3 Jahren mit Unit Testing, ca. 60% davon privat, weil es in den Firmen noch extremen Nachholbedarf gibt. Meinen Kenntnissstand würde ich als fortgeschritten bezeichnen, auf keinen Fall bin ich ein Routinier/Profi in diesem Bereich. In der Theorie kenne ich 90% der Möglichkeiten, in der Praxis bringt das leider wenig, wenn es darum geht Deadlines einzuhalten! Da hilft mir nur am Ball bleiben und Routine sammeln.

 

[DerFeivel]

Grundsätzlich stimme ich dir zu deetee.
Allerdings habe ich hierzu noch eine Anmerkung:

Bei einem Refactoring ändern sich selten Schnittstellen, vorallem keine öffentlichen. Auch die Testvoraussetzungen bleiben die selben, weil ja das Ziel von Refactoring keine neue Funktionaliät ist, sondern das Programm soll nachher genauso funktionieren, wie es vor dem Refactoring lief.

Ich bin mir nicht sicher, aber ich glaube, er bezog auch die Schnittstellen zwischen den einzelnen Units mit ein.
Hier kann es bei einem Refactoring ja durchaus auch zu Änderungen kommen (habe ich selbst gerade durch). Beispielsweise wenn man eine Klasse refactored die in ihrer alten Version mehrere Responsibilities erfüllt in mehrere Klassen aufteilt.
Aber selbst dann ändert sich das getestete Verhalten nicht, so dass sich in der Regel der Aufwand hier oftmals auch in Grenzen hält.


Unabhängig davon:

Gerade bei großen, komplexen Programmen spielen Unit-Test ihre eigentliche Stärke erst aus. Selbst der fähigste Entwickler verliert bei mehren Dutzend Klassen irgendwann den Überblick.
Unit-Tests helfen hier dem Entwickler das nach außen "sichtbare" Verhalten der Unit (i.d.R. also der Klasse/Komponente) stabil zu halten.
Die Test sind also sozusagen eine FSK der Entwickler.

Für die neuen Entwickler heisst es halt:
Wenn ich ein neues Feature einbaue, verhält sich die Komponente/die Features der Komponente danach immernoch genauso wie vorher. Es sollte also somit auch im eigenen Interesse eines jeden Entwicklers sein, Unit-Tests zu schreiben um nicht permanent an dem selbstentwickelten Feature herumdoktern zu müssen.

 

[maki]

Naja - auf der anderen Seite: in der heutigen Zeit gibt es kaum Entwickler die sich ordentlich einarbeiten wollen/können weil die Projekte zu kurzfristig angelegt sind. Vielleicht ist das übliche "Fire & Hire"-Geschäft die Keimzelle für das überbordende Testen statt alle Kraft in die Weiterenticklung zu stecken.

Die Keimzelle für "überbohrtes Testen" war das streben nach Qualität.
Selbst erfahrene Enwickler machen Fehler, auch die müssen Testen, automatisieren spart einem viel Arbeit während es die Qualität in bestimmten Bereichen sicherstellt, nämlich den getesteten Bereichen.

Ohne ständiges Refactoring "vergammelt" Code bzw. die ganze Software, Refactoring ohne Tests ist ein Spiel mit dem Feuer -> Teufelskreis

Das alles funktioniert IME übrigens nicht wenn man nur ein paar Monate in einem Projekt bzw. bei einem Kunden ist, wozu denn auch? "Nach mir die Sinnflut..."

 

[Bernd Hohmann]

Die Probleme, die Du beschrieben hast, hat man doch auch ohne Unit-Tests. Der Vorteil bei Unit-Tests ist ja ebenfalls, dass solche Tests die Funktionalität dokumentieren. Sprich, wenn eine neue Person im Projekt den Code anfasst und dazu einen Test findet, weiß sie ungefähr, was bisher dort passieren sollte. Dementsprechend kann der Test auch von unerfahrenen Entwicklern angepasst werden. Ohne den Test hätte die Person auf jeden Fall weniger Wissen, oder nicht?

Das ist natürlich ein schlagkräftiges Argument: in den Tests findet man ein recht isoliertes Muster wie die Funktion "anzufassen" ist.

Bernd

 

[Bernd Hohmann]

Die Budgets und Deadlines geben oft nicht den Raum für große qualitätsfördernde Maßnahmen. Deswegen ist es so wichtig, dass Entwickler in der selben Zeit besseren Code schreiben lernen. Unit Testing ist dafür ein guter Weg, allerdings benötigt man einige Jahre um wirklich auf ein gutes Niveau zu kommen. Ich beschäftige mich seit gut 3 Jahren mit Unit Testing, ca. 60% davon privat, weil es in den Firmen noch extremen Nachholbedarf gibt. Meinen Kenntnissstand würde ich als fortgeschritten bezeichnen, auf keinen Fall bin ich ein Routinier/Profi in diesem Bereich. In der Theorie kenne ich 90% der Möglichkeiten, in der Praxis bringt das leider wenig, wenn es darum geht Deadlines einzuhalten! Da hilft mir nur am Ball bleiben und Routine sammeln.

Das ist ein ehrliches Statement von jemanden der tief in der Materie drinsteckt - damit kann ich was anfangen.

Denn bislang hatte ich den Eindruck, dass man mit leichter Hand einen Unittest schreibt um auch komplexe Themen abzuwickeln - da hat sich meine Erfahrung gesperrt.

Aber wenn Unittests bedeuten, dass man auch mal viel Sch**sse fressen muss (in der Firma wie auch Privat) um das ordentlich zu machen - da bin ich schon wieder dabei!

Danke für die Auflösung meines gedanklichen Knotens, unter diesen Voraussetzungen full ACK für den Rest Deines Textes.

Bernd

 

[deetee]

Das freut mich, dass du wieder "auf" gemacht hast. Ich glaube ich muss mir da auch ein Beispiel nehmen, weil ich eine ähnliche Haltung habe was eine momentan gehypte Praktik angeht: Scrum! Ich finde Scrum eigentlich gut, verstehe aber nicht, warum alles alte nun schlecht sein soll und mit Scrum alles besser. Aber das Thema ist mindestens 1 eigener Thread wert.

Gern würde ich hier jetzt noch auf angerissene Themen eingehen, z.B.

1. Wie "verkaufe" ich Unit Testing meinen Vorgesetzten?
2. Welche Maßnahmen sind notwendig, um Unit Testing professionell zu betreiben?
3. Wie denken Vorgesetzte über Unit Testing und andere QA Maßnahmen?

Das würde aber ebenfalls den Thread sprengen. Vielleicht mach ich mal einen neuen auf.

 

[Sym]

Das Thema Unit-Tests hat eigentlich auch diesen Thread schon gesprenkt...

 

[DerFeivel]

1. Wie "verkaufe" ich Unit Testing meinen Vorgesetzten?

Wenn deine Firma/Abteilung ein Ticket-System benutzt wäre ein mögliches Vorgehen der Weg über Statistiken (da sind leitende Angestellte meist ganz verrückt nach ).

Ein guter Indikator für Unit Tests wären dann Komponenten/Features an denen immer wieder herumgedoktort wird/werden muss, weil neue Anpassungen ältere Anpassungen sprengen.
Wäre ja sowas wie DER Fall für Unit-Tesging.


Eventuell kann dir bei der Argumentation auch sowas hier helfen:

http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf (Hab das Paper jetzt nicht nochmal durchgelesen, aber hier sollte es um den Vergleich der Fehlerdichte in TDD und Non-TDD Entwicklerteams gehen)

2. Welche Maßnahmen sind notwendig, um Unit Testing professionell zu betreiben?

Know your tools.

Best Practices, wie bspw. einen bestimmten Aufbau der Tests (Given / When / Then fällt mir da gerade ein)

1-2 TDD-erfahrene Entwickler (wir hatten das Glück ein TDD-erfahrenes Team zu bekommen)


Und, ach ja:

Ganz wichtig:

Vorgesetzte die Unit-Testing akzeptieren .

3. Wie denken Vorgesetzte über Unit Testing und andere QA Maßnahmen?

Einzelfallbasiert.

Aufgrund Ihrer Funktion als Team- /Projektleiter würde ich aber vermuten eher wenig. Kostet auf den ersten Blick ja nur Zeit und die ist ja bekanntlich Geld

 

[Bernd Hohmann]

Ich finde Scrum eigentlich gut, verstehe aber nicht, warum alles alte nun schlecht sein soll und mit Scrum alles besser.

Wie ich paar Postings vorher zu Dir gesagt hat: "warts ab, in 10 Jahren wird eine neue Sau durchs Dorf getrieben und dann schreibst Du hier 'warum soll ich das machen, das alte läuft doch so gut'.

Mein langjähriger Kollege und ich betreiben Scrum und Extreme Programming im Grunde genommen schon seit .. 1995 oder so (also noch bevor es "erfunden" wurde).

Das ergab sich bei uns einfach aus der Tatsache, dass wir a) eine recht gereifte, aber krude API b) keine Debugger oder IDEs mit Syntaxhighlighting hatten. Da kommt man schnell auf Methoden die heute zb. unter Pair-Programming und Test-Driven-Development bekannt sind.

Bei solchen Sachen wie Scrum, agile Softwareentwicklung etc. sollte man immer im Hinterkopf behalten dass es sich nicht um Entwicklungsmethoden der Sorte 1+1=2 sondern um Entwicklungskultur handelt die im Kontext der Autoren entstanden ist und nicht unbedingt 1:1 auf die (Entwicklungs)Kultur der Deutschen adaptierbar ist.

Mal überspitzt gesagt: Wärend der Deutsche noch sorgenvoll in die Zukunft schaut, ist der Amerikaner schon auf der nächsten Party. Sowas wie Scrum wird in anderen Ländern als neue Idee aufgegriffen, in DE eher als Dogma aufgefasst was die Adaption sehr schwierig macht weil eine Abweichung von der reinen Lehre ein Sakrileg ist.

Nimm von Scrum was zum Unternehmen passt, sind ja genügend Bausteine vorhanden.

Bernd

 

[maki]

Mein langjähriger Kollege und ich betreiben Scrum und Extreme Programming im Grunde genommen schon seit .. 1995 oder so (also noch bevor es "erfunden" wurde).

Wirklich?
So mit TDD, Pair Programming, CI (inkl. Server), etc. pp.?
Glaub ich nicht, zumindest was xP betrifft

Scrum dagegen, also agile vorgehensweisen, das glaube ich gerne.

 

[Bernd Hohmann]

Wirklich?
So mit TDD, Pair Programming, CI (inkl. Server), etc. pp.?
Glaub ich nicht, zumindest was xP betrifft

Doch doch.

Was es nicht gab waren automatisierte Tests - dafür hatten wir eine Vorgehensweise die man heute als "Pen & Paper Testunit" beschreiben würde. Dh. ehe man das Programm (meisstens eine Faktura oder FiBu) erweitert hat, wurden auf einem Blatt Papier sämtliche Eingabeparameter und Ausgabeparameter aufgeschrieben und dann nachgedacht "Für diese Eingabewerte erwarte ich folgende Ausgabewerte, wie komme ich da hin, welche Fallstricke sind zu erwarten". Am Ende wird das dann mit anderen Testwerten überprüft und wegprogrammiert. Das ganze so, dass immer ein lauffähiger Stand beibehalten wird und der Zyklus "Entwurf, Programmierung, Test" recht kurz bleibt.

Und natürlich meisstens zu zweit. Oft etwas anstrengend (der "passive" Entwickler entwickelt dabei meisst eine Technik für einen erholsamen Sekundenschlaf - wärend der Kollege die Doku erweitert kann man mal 30sek wegpennen. Nach 4 Stunden ist man kaputter als nach 2 Tagen Schlammschippen).

Was halt damals zu Diskettenzeiten auch nicht ging war die starke Integration des Kunden. Da blieb es bei regelmässigen Telefonaten und es sind ständig Faxe mit Mustermasken oder Probedrucken herumgegangen und wenn ein Zwischenstand erreicht war, wurde der zum herumspielen ausgeliefert. Aber lieber bin ich mal paar Stunden (oder auch Tage) in den Betrieb gefahren um zu sehen, wie die Anwender dort ticken und wie die Arbeitsabläufe sind.

Heute ist das dank Telefon/Internetflatrate und VPN alles kein Thema mehr. Ich hab eben eine Änderung auf einen Rechner 300km entfernt eingespielt und via Telefon und VNC mit dem Kunden darüber diskutiert ob das so seinen Vorstellungen entspricht.

Ja, wir konnten das schon vor den Amis und war immer verblüfft, wie verstaubt andere Betriebe waren

Bernd

 

[deetee]

Doch doch.

Was es nicht gab waren automatisierte Tests - dafür hatten wir eine Vorgehensweise die man heute als "Pen & Paper Testunit" beschreiben würde. Dh. ehe man das Programm (meisstens eine Faktura oder FiBu) erweitert hat, wurden auf einem Blatt Papier sämtliche Eingabeparameter und Ausgabeparameter aufgeschrieben und dann nachgedacht "Für diese Eingabewerte erwarte ich folgende Ausgabewerte, wie komme ich da hin, welche Fallstricke sind zu erwarten".

Das wird auch hier und da heute noch so gemacht und ich kenne es als CTE.

Es gibt auch Editoren dafür, aber einen guten kostenlosen konnte ich noch nicht finden. Leider ist es auch sonst digital per Wiki Syntax o.ä. etwas kompliziert zu zeichnen, daher geht es per Hand meist schneller. Allerdings ist es auf dem Papier schlecht für nachhaltige Dokumentation, daher spar ich mir das immer mehr. Außerdem kennt es kein Mensch mehr, leider. Auch Entscheidungstabellen sind eigentlich extrem praktisch, aber leider auch am aussterben.

 

[maki]

Was es nicht gab waren automatisierte Tests - dafür hatten wir eine Vorgehensweise die man heute als "Pen & Paper Testunit" beschreiben würde. Dh. ehe man das Programm (meisstens eine Faktura oder FiBu) erweitert hat, wurden auf einem Blatt Papier sämtliche Eingabeparameter und Ausgabeparameter aufgeschrieben und dann nachgedacht "Für diese Eingabewerte erwarte ich folgende Ausgabewerte, wie komme ich da hin, welche Fallstricke sind zu erwarten". Am Ende wird das dann mit anderen Testwerten überprüft und wegprogrammiert. Das ganze so, dass immer ein lauffähiger Stand beibehalten wird und der Zyklus "Entwurf, Programmierung, Test" recht kurz bleibt.

Ne, das ist kein xP.
Auf Papier kommt im xP erstmal gar nix, nur Code zählt.
Keine Kopfgeburten, sondern echte Lösungen die aus der Praxis kommen und erstmal funktionieren, vor allem aber getestet sind, bevor sie geschrieben wurden
Zuklus in xP ist eher der aus TDD:
Test schreiben, Prod Code anpassen bis der Test durchgeht, dann Refactoring.
Also umgeklehrt zu dem was du beschrieben hast.

 

[FArt]

Nimm von Scrum was zum Unternehmen passt, sind ja genügend Bausteine vorhanden.
Bernd

Das ist Scrumbut und oft ein Grund, warum Scrum nicht funktioniert. Scrum ist nun mal (absichtlich) relativ dogmatisch ausgelegt.

Wenn man es etwas freier haben möchte, sollte man es eher mit Kanban versuchen und dies mit anderen Techniken kombinieren.

 

[Bernd Hohmann]

Das ist Scrumbut und oft ein Grund, warum Scrum nicht funktioniert.

Ich dachte, Scrum-but wurde mittlerweile durch Scrum-and ersetzt?

Bernd

 

[Kratzer]

Ich kann dir nur raten, ganz old-school wie du es gelernt hast mit den hierarchischen Klassenstruukturen zu arbeiten. Spätestens, wenn du im Team arbeitest, werden dich dein Kollegen sonst verfluchen.:autsch:

 

[FArt]

Ich dachte, Scrum-but wurde mittlerweile durch Scrum-and ersetzt?
Bernd

Scrum-and hört sich positiver an und ist eher ein Anpassungsprozess, dem oft zu strikten Scrum geschuldet... Scrum-but ist eher eine eigenmächtige Anpassung zur Verwässerung von Scrum, oft mit dem Ergebnis, dass Scrum nicht funktioniert, da hier oft nicht das Ziel existiert (oder zumindest nicht erreicht wird), den Prozess auf Scrum im Laufe der Zeit umzustellen.