Laden...

Tatsächlicher Nutzen von Unit-Tests [und TDD]

Erstellt von Rainbird vor 13 Jahren Letzter Beitrag vor 13 Jahren 53.354 Views
Rainbird Themenstarter:in
3.728 Beiträge seit 2005
vor 13 Jahren
Tatsächlicher Nutzen von Unit-Tests [und TDD]

Hallo zusammen,

wenn man der Fachpresse glaubt, dann gehören Unit-Tests zum Guten Ton in der Branche und sollten quasi eine Selbstverständlichkeit sein. Ist das wirklich so?

Ich selbst habe Zeifel am Nutzen von Unit-Tests, wenn man den Aufand ins Verhältnis setzt. Führt der sachgemäße Einsatz von Unit-Tests tatsächlich zu qualitativ hochwertiger Software?

Und wenn ja, gibt es eindeutige messbare Beweise dafür?
Was sind Eure Erfahrungen mit Unit-Tests?

Vielleicht können wir diesen Fragen zusammen sachlich auf den Grund gehen.

Interessant ist in diesem Zusammenhang auch der folgende Thread: Alltag in unserer Branche (?)

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Rainbird,

ich vermisse bei der Abstimmung ein einfaches "Ja" oder von mir aus ein "Ja, weil es nützlich ist". Man muss ja nicht gleich alles "aus voller Überzeugung" oder gar "aus vollster Überzeugung" einsetzen.

Außerdem trenne ich:

Unit-Tests spielen in meinen Augen ihre Vorteile vor allem bei grundlegenden und Infrastruktur-Klassen aus. Wenn man solche Klassen schreibt, schafft man in der Regel ein Angebot an Properties und Methoden, von dem in dem konkreten Programm, wo man solche Klassen zuerst verwendet, sicher nur ein Teil einsetzt wird. Deshalb ist mit dem Test des Programms alleine noch nicht gezeigt, dass die Klasse im korrekt ist (ok, man kann durch Tests normalerweise eh nicht die Korrektheit beweisen). Außerdem ist es bei grundlegenden und Infrastruktur-Klassen besonders wichtig, dass diese in allen Situationen korrekt und robust funktionieren. Hier spielen also Unit-Test ihre volle Stärke aus.

Bei Modellklassen bringen Unit-Test meiner Erfahrung nach weniger. Denn zum einen Implementiert man hier viel häufiger nur die Methoden, die tatsächlich genutzt werden und außerdem müssten die auch nur in dem Wertebereich funktionieren, in dem das Programm sie benutzt. Durch den Test des Programms, kann man quasi indirekt zeigen, dass auch die Modellklassen (für den konkreten Einsatzzweck) geeignet sind.

Soweit, dass ich konsequent testdriven implementiere, gehe ich aber nicht. Ich habe zwar einen Enwicklungsstil, der nach kleinen Änderungen immer einen Compile- und teilweise auch Testlauf einfügt, aber konsequent testdriven im Sinne von TDD ist das trotzdem nicht.

herbivore

2.891 Beiträge seit 2004
vor 13 Jahren

Ich denke, man muss auch beachten, dass ein Unittest nicht einfach nur eine Ampel darstellt, die Rot oder Grün zeigt und dir sagt, ob dein Code Bugs hat oder nicht (wobei "oder nicht" nicht entscheidbar ist). Um Unittests mit einer Codebasis durchführen zu können, müssen ja bestimmte Vorraussetzungen erfüllt sein - der Code muss testbar sein. Und um das zu erreichen, muss man eine entsprechende Architektur erstellen (z.B. bestimmte Komponenten austauschbar machen, feste Abhängikeiten lösen usw).

Ich würde sogar fast so weit gehen und sagen, dass das der Hauptnutzen von Unittests ist und Fehler entdecken nur eine netter Nebeneffekt ist.

Gruß,
dN!3L

Rainbird Themenstarter:in
3.728 Beiträge seit 2005
vor 13 Jahren
Tests als Treiber für saubere Architektur

Ich würde sogar fast so weit gehen und sagen, dass das der Hauptnutzen von Unittests ist und Fehler entdecken nur eine netter Nebeneffekt ist.

Dann ist der Vorteil der Tests - wenn ich das richtig verstanden habe - dass man gezwungen wird, eine ordentliche Architektur aufzubauen. Wenn man testbare Software schreibt, muss sie in die zu testenden Bestandteile zerlegbar sein. Also erstellt man besser strukturierte Software, um den automatischen Test zu ermöglichen.

@herbivore: Abstimmung korrigiert.

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Rainbird,

Dann ist der Vorteil der Tests - wenn ich das richtig verstanden habe - dass man gezwungen wird, eine ordentliche Architektur aufzubauen.

Nein, das ist bei weitem nicht der einzige Vorteil. Der Hauptnutzen von Unit-Test ist natürlich, dass man nicht nur bessere Aussagen über die Korrektheit bekommt, sondern dass die Software in der Regel tatsächlich weniger Fehler hat.

Außerdem wird durch Unit-Tests das Refactoring erleichtert, denn man kann ja immer leicht schauen, ob ein Refactoring tatsächlich nichts am beobachtbaren Verhalten der Unit geändert hat. Manche sagen, dass Unit-Tests Refactoring überhaupt erst ermöglichen, weil sonst die Gefahr, durch Refactoring unbeabsichtigt neue Fehler einzubauen, einfach zu hoch ist. Dieser Auffassung bin ich sehr zugeneigt.

Außerdem hat man in jeder Projektphase ein bessere Aussage über die Korrektheit des erzeugten Code und damit mehr Planungssicherheit. Man vermeidet, dass beim Integrationstest der große Knall kommt, weil die Komponenten in sich noch (viele) Fehler enthalten.

herbivore

2.891 Beiträge seit 2004
vor 13 Jahren

Nein, das ist bei weitem nicht der einzige Vorteil.

Und im Falle von API-Assemblies hat man auch gleich eine Art von Dokumentation.

Ich muss aber auch gestehen, dass UnitTests an sich für mich keine Selbstverständlichkeit sind. In Legacy/Brownfield-Anwendungen lässt es die Zeit/das Budget einfach nicht zu, dass Tests nachgerüstet werden. Ebenso bekommen kleinere Anwendungen keine Unittests verpasst. Meiner Erfahrung nach lassen sich auftretende Bugs in der Regel sehr leicht reproduzieren; der Rest sind irgendwelche Race-Conditions, die man m.E. mit UnitTests auch nicht gefunden hätte. Von daher ist das Nutzen im Verhältnis zum Aufwand einfach nicht gegeben.
Das könnte allerdings auch ein Trugschluss sein - weswegen ich mir wünschen würde, mal alle Projekte mit Unittests ausstatten zu können. Was mich natürlich nicht davon abhält, die Komponenten testbar zu implementieren, sodass Unittests theoretisch möglich wären.

Gruß,
dN!3L

5.742 Beiträge seit 2007
vor 13 Jahren

Hallo zusammen,

ich nutze UnitTests und werde sie nach meinen bisherigen Erfahrungen auch weiterhin einsetzten.

Den von dN!3L angesprochenen Punkt halte ich ich für sehr wichtig, möchte ihn allerdings noch ergänzen:
Manchmal stellt man auch erst durch den UnitTest fest, dass die Spezifikationen für manche Klassen teilweise widersprüchlich oder unvollständig sind.
Manchmal will ich etwas testen und merke: "Hoppla - das geht ja gar nicht so" oder "Was soll überhaupt passieren, wenn X auftritt?".

Auch stelle ich manchmal erst beim Testen fest, dass ich manche Dinge gar nicht brauche (bzw. diese Dinge besser in eine weitere Klasse ausgelagert werden sollten), wenn manche Tests sehr speziell sind, sehr komplex zu schreiben sind oder mit anderen Tests für die Klasse nicht wirklich etwas zu tun haben.

Einen weiteren Vorteil sehe ich darin, dass man schneller Erfolgserlebnisse hat: Jeder erfolgreiche Test ist ein "Schritt" auf dem Weg zum fertigen Projekt.

Das ganze hat aber auch seine Kehrseite:
Häufig denke ich dann auch "Muss ich das jetzt wirklich testen? Es ist doch offensichtlich, dass das funktioniert" (manchmal stellt sich dann aber doch heraus, dass der Test nicht ganz sinnlos war^^).
Subjektiv gesehen braucht man mit UnitTests auf jeden Fall länger.

Aber das hat auch wieder den Vorteil, dass man versucht, die Funktionalität einer Klasse so zu dimensionieren, dass man sie mit möglichst wenigen Tests abdecken kann. Das kommt dann der Einfachheit vieler Klassen zu gute - es ist doch erstaunlich, wie viel eine Klasse nicht können muss und was man dann durch eine weitere Klasse "nachrüsten" kann, wo man es braucht.
Die Idee von TDD, erst einen Test zu schreiben und diesen dann so einfach wie möglich erfolgreich durchlaufen zu lassen, gefällt mir in diesem Zusammenhang auch sehr gut.

Allerdings merke ich, dass ich teilweise noch relativ viel Zeit zum Erstellen von Mocks / Stubs benötige - gerade RhinoMock verhält sich häufig nicht so, wie ich das gerne hätte.
Und das wirkt teilweise richtig demotivierend 🙂

Zum Thema Refaktoring:
So lange man das klassenintern durchführt, stimme ich zu, dass UnitTests da wirklich Gold wert sind.
Geht es allerdings an Refaktorings wie das Verschieben von Methoden oder Extrahieren von Klassen, sind die UnitTests in manchen Situationen eher hinderlich, da man sie auch abändern muss.
Da kommen dann wirklich Integrationstests ins Spiel. Aber ich schweife ab...

6.911 Beiträge seit 2009
vor 13 Jahren

Hallo,

Außerdem wird durch Unit-Tests das (klasseninterne) Refactoring erleichtert, denn man kann ja immer leicht schauen, ob ein Refactoring tatsächlich nichts am beobachtbaren Verhalten der Unit geändert hat.

Das ist für mich das Haupteinsatzgebiet von Unit-Tests. Wenn ich zB irgendwann einen Code optimiere kann ich durch den Test bestätigen dass das sich das Verhalten nach außen hin nicht verfälscht hat.

Nach TDD gehe ich allerdings nicht immer vor sondern meist zuerst Implementierung -> Test.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

71 Beiträge seit 2010
vor 13 Jahren

Unit Tests und TDD und Akzeptanztests usw. sind natürlich zu unterscheiden. Aber die Feinheit mag zunächst hintangestellt sein. Ich werfe also mal in einen Topf und nenne die Vorteile von automatisierten Tests im Allgemeinen:

-Automatisierte Tests werden garantiert ausgeführt. Immer. Von manuellen Tests kann man das nicht sagen. Selbst wenn ein dickes Handbuch mit allen manuell auszuführenden Tests vorliegen sollte, gibt es keine echte Nachvollziehbarkeit, welche davon tatsächlich ausgeführt werden. Nur automatisierte Tests bieten also irgendeine Form von Nachweis.

-Automatisierte Tests haben eine viel größere Performance als manuelle Tests. Nur automatisierte Tests lassen sich daher häufig ausführen. Und nur deshalb kann man sie vernünftig kumulieren. D.h. ich kann immer alle Tests ausführen. Das mag am Ende vielleicht Stunden dauern - im Vergleich dazu würden aber manuelle Tests Tage und länger dauern. Also bieten nur automatisierte Tests verlässlich Schutz vor Regressionsfehlern (auf Deutsch: Verschlimmbesserungen 😉

-Automatisierte Tests können beliebige Granularität haben. Sie können grob sein (Integrationstest) oder ganz klein (Unit Test einer Methode). Nur mit automatisierten Tests ist daher verlässlich und nachvollziehbar Fehlerfreiheit im Rahmen der Tests demonstrierbar.

-Um die Zahl der Tests minimal zu halten, ist zwischen Unit Tests und Integrationstests zu unterscheiden. Wer automatisiert testet, achtet daher darauf, Unit Tests auf möglichst kleinen Einheiten zu fahren. Damit treibt er ein Design voran, dass nicht nur gut testbar, sondern auch flexibel ist (SRP). Tests dienen also nicht nur der Korrektheitsprüfung, sondern auch der Strukturierung (TDD).

-Automatisierte Tests können nicht nur laufen, sondern auch gelesen werden. Sie stellen damit eine Form der Dokumentation dar. Aus einem Test kann man ablesen, wie Funktionseinheiten zu benutzen sind.

-Automatisierte Tests können vor der Implementation geschrieben werden. Das hilft beim Outsourcing. Denn dann kann man Tests an den Lieferanten übergeben, der erst abliefern darf, wenn die Tests fehlerfrei durchlaufen werden (semantischer Kontrakt).

-Tests können nicht nur als Dokumentation der intendierten Benutzung von Funktionseinheiten verstanden werden, sondern auch als Dokumentation des Wissens über die Problemdomäne. Im Test stehen nämlich die Erwartungen des Kunden drin: "Zum Input X erwarte ich den Output Y." Wer an automatisierte Tests denkt, der fragt daher den Kunden auch anders, präziser. Das kann jeder bei einem Coding Dojo in seiner Nähe ausprobieren: Es ist immer wieder überraschend, wie selbst bei allereinfachsten Problemen die Gruppen drauflosprogrammieren wollen. Dabei könnten sie viel effizienter arbeiten, wenn sie mehr nachfragen würden. Und das passiert sogar obwohl bei Coding Dojo das autom. Testen so groß geschrieben wird.

-Autom. Tests zu schreiben ist eine Form der Reflexion. Während der Arbeit wechsle ich die Sichtweise. Gerade wo kein Pair Programming möglich ist und Code Reviews selten sind, ist das zumindest eine kleine Kompensation.

Welche weiteren Vorteile gibt es? Hm... Fürs erste sollte es reichen.

Hoch- und Tiefbau, Maschinenbau und auch Elektrotechnik haben Physik, Chemie, Mathematik zu ihrer Hilfe. Mit ihnen können sie sehr weitreichend schon eruieren, ob ein Entwurf im wahrsten Sinn des Wortes tragfähig ist.

Die Softwareentwicklung hat nichts dergleichen. Soll sie deshalb aber bei manuellen Tests stehenbleiben? Das wäre pure Dummheit.

Die ganze Industriewelt lebt von Automatisation. Das kann die Softwareentwicklung auch. Compiler sind ein Beispiel. Soll sie deshalb aber da stehenbleiben? Das wäre pure Dummheit.

Softwaresystem kann man und sollte man daher automatisiert bauen lassen.

Softwaresysteme kann man und sollte man daher automatisiert testen lassen.

Dass man dafür einen gewissen Aufwand treiben muss, das ist natürlich. Tests schreiben sich nicht von allein.

Aber der Gewinn ist vielfältig (s.o.).

Und wer es nicht für einen Gewinn hält, auf einen Knopf drücken zu können, um ohne weiteres Zutun zu erfahren, ob die Software nach mehr oder weniger großen Änderungen immer noch komplett korrekt (im Sinne der Tests) ist... sorry, da fehlen mir dann irgendwann auch die Worte.

Oder es mangelt einfach nur am Erlebnis. Das muss man einfach mal erlebt haben. Ja, genau. Man muss es sich gönnen, das zu tun.

Und bitte nicht an der Stelle auf den Chef verweisen. "Der Chef erlaubt uns keine Unit Tests." Das ist - mit Verlaub - Quatsch. Denn das ist, als würde der Krankenhausgeschäftsführer sagen, "Bei uns werden die Instrumente nicht sterilisiert."

Autom. Testen ist absolut state-of-the-art. Punkt. Es ist international ab-so-lut anerkannt. Und insofern gehört es schlicht zu einer professionellen Haltung, automatisiert zu testen. Einfach tun. Nicht fragen. Niemanden! Ja, das meine ich so. Niemand muss gefragt werden, ob man als Entwickler einen autom. Test schreiben darf. Man tut es einfach.

Aber ich verstehe... Die Hygieneregeln haben sich vor 160 Jahren auch nicht einfach so durchgesetzt. Also müssen wir noch warten, bis auch der letzte Student nicht mehr anders kann und will, als automatisiert zu testen.

-Ralf

175 Beiträge seit 2010
vor 13 Jahren

Ich selbst habe Zeifel am Nutzen von Unit-Tests, wenn man den Aufand ins Verhältnis setzt. Führt der sachgemäße Einsatz von Unit-Tests tatsächlich zu qualitativ hochwertiger Software?

Ich pers. habe zu Unit Tests einen mehr oder weniger gestörtes Verhältnis 😉

Spaß beiseite. Ich denke man muss da unterscheidem, für welches Teil eines Projektes man die Unit-Tests schreibt.

Nehmen wir an, ich entwickle eine "StringHelper" Klasse, die halt vorwärts und rückwärs völlig schräge Sachen mit Strings machen kann. Natürlich sind da Unit-Tests eine absolute Notwendigkeit. Und jeder später gefundene Bug wird in die Unit-Tests aufgenommen. Bei "Low-Level" Zeuchs finde ich Unit-Tests sehr wichtig!

Bei High-Level Zeuchs benutze ich pers. Unit-Tests eher für Tests, bei denen ich die Klassen/Methoden mit ungültigen Werten befeuere und hier eine gewisse Stablilität sicherstellen möchte. Dass die Klassen/Methoden das tun, wofür diese gedacht sind stelle ich dann eher durch Systemtests sicher (natürlich behalte ich dabei die Codeüberdeckung im Auge!)....

Die Ausführung von Systemtests und Unittests wird durch einen Integrationsserver (z. B. Hudson) sichergestellt.

Bye,
Michael

Debuggers don't remove Bugs, they only show them in Slow-Motion.

M
153 Beiträge seit 2010
vor 13 Jahren

Also das mit den Chefs ist so eine Sache der Argumentation. Niemend möchte Zeit und Geld in Tests investieren, sondern für fertige Software. Fehlerfreiheit wird da schnell als Selbstverständlichkeit abgetan. Die Argumentation muss vielmehr lauten: Für x Tage mehr haben wir über den gesamten Lebenszyklus der Anwendung Ruhe, für eine ganze Reihe möglichweise auftretender Fehler. Das spart Supportaufwände, manuelle Tests, erhöht die Kundenzufriedenheit und erlaubt dann wieder den Blick auf Funktionalität - und wir können ruhiger schlafen.

Ich persönlich halte das Argument der persönlichen Reflexion für sehr gewichtig, es ändert einfach die Einstellung des Entwicklers.

Das richtige Maß für den "gewissen Aufwand" halte ich aber für wichtig, wo liegt er denn? Natürlich, bei jeder Anwendung und für jede Funktion irgendwo anders. Aber gibt es vernünftige Metriken, Vergleiche oder eine Hilfe für den gesunden Menschenverstand?

Was mir persönlich gut gefällt sind die neuen Einschränkungen im TFS und die neuen Testmethoden in Visual Studio 2010. Sie erlauben es, in einzelnen Fällen, Unittests auf höheren Ebenen durchzuführen (beispielsweise durch die Automated UI Tests) und dennoch geht die Automatisierung nicht verloren.

M
164 Beiträge seit 2009
vor 13 Jahren

Mich würden die Argumente der UnitTest-Abgeneigten interessieren.

Welche Gründe - ausser der zusätzliche Zeitaufwand - gibt es? (Zeit ist Geld, etc...)

185 Beiträge seit 2005
vor 13 Jahren

hallo,

ein Grund gegen Unittests ist ev.: Das Programm hat insgesamt < 50 Zeilen Code. 😉

Wichtig ist wohl noch "korrekte" Unittests zu schreiben (da bin ich auch noch am lernen) und zu unterscheiden zwischen Unittests und Integrationtests. Der größte Vorteil für mich ist, dass ich mir "traue", Refactorings zu machen, wenn ich für den betroffenen Code (besser: den gesamten Code) automatische Tests habe.

fg
hannes

F
60 Beiträge seit 2010
vor 13 Jahren

Aber ich verstehe... Die Hygieneregeln haben sich vor 160 Jahren auch nicht einfach so durchgesetzt. Also müssen wir noch warten, bis auch der letzte Student nicht mehr anders kann und will, als automatisiert zu testen.

Offensichtlich hat die Industrie aber noch nicht begriffen, wie wichtig ordentliches softwaredesign im richtigen leben ist, ansonsten würden studenten tatsächlich von agiler softwareentwicklung und tdd hören, anstatt mit algo, datenstrukturen, c, java und mathe überladen zu werden.
das handwerkszeug kann man sich schnell selbst bei bringen, gutes softwaredesign lernt man aber von erfahrenen leuten und durch try&error, wofür umfangreichere softwareprojekte auch im studium bearbeitet werden müssten. dafür fehlt vor allem bei den neuen bachelor studiengängen bei aktuellem stoffplan schlicht die zeit. die forderung der industrie ist definitiv nicht laut genug (siehe anzahl an studiengängen technische informatik vs software engineering), ansonsten hätte sich schon was geändert.

zur umfrage: technisch ist mir klar, wie und warum tdd benutzt wird. wirklich sauber zu testen, lernt man allerdings eher im richtigen leben von erfahrenen leuten und richtigen projekten. daran mangelt es mir im moment leider massiv. deswegen: nein, aber schon fleißig am üben

2.921 Beiträge seit 2005
vor 13 Jahren

@Rainbird:

Ein Verweis hierauf sei noch erwähnt:

Meine Erfahrungen zu Unit-Tests

Auszug aus Clean Code:

The moral of the story is simple: Test code is just as important as production code. It
is not a second-class citizen. It requires thought, design, and care. It must be kept as clean
as production code.

Außerdem sollte inzwischen TDD state of the Art sein, wie ja hier von anderen auch schon erwähnt wurde.

Ich habe nur gute Erfahrungen mit Unit-Tests gemacht.

Und man schreibt den Code doch etwas anders. Flexibler.

Außerdem hat man den Vorteil wenn man z.B.

Testdriven (C#) .NET

benutzt, bekommt man tools wie Code Coverage durch die Unit-Tests zusätzlich hinzu oder ein Visual Studio plugin mit dem man direkt nur die zu testende Methode ausführen lassen kann, egal ob im Test oder direkt im produktiven Code. Sehr zeitsparend.

Ich behaupt einfach mal dass Unit-Tests ab einem bestimmten Projektumfang IMMER den Zeitaufwand hinten raus reduzieren.

Und dass der produktive Code durch die Unittests besser wird, ist IMHO auch Tastache.

Auch die Conclusion aus Clean Code spricht für sich und kann der Aussage nur zustimmen:

Conclusion
We have barely scratched the surface of this topic. Indeed, I think an entire book could be
written about clean tests. Tests are as important to the health of a project as the production
code is. Perhaps they are even more important, because tests preserve and enhance the
flexibility, maintainability, and reusability of the production code. So keep your tests constantly
clean. Work to make them expressive and succinct. Invent testing APIs that act as
domain-specific language that helps you write the tests.
If you let the tests rot, then your code will rot too. Keep your tests clean.

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

S
72 Beiträge seit 2009
vor 13 Jahren

Ich muss fielding & HannesB zustimmen.

Ich finde es teilweise recht schwierig "korrekte" Unittests zu schreiben und auch im "richtigen" Maße.

Der Dotnet Pro Artikel von RalfW mit Golo Roden war schon hilfreich was die ungefähre Richtung der Unittests angeht. Aber irgendwie fehlt da noch das "Ah! So sollte das laufen"-Effekt.

Gruß
Stefan

Rainbird Themenstarter:in
3.728 Beiträge seit 2005
vor 13 Jahren
Beweise

Außerdem sollte inzwischen TDD state of the Art sein, wie ja hier von anderen auch schon erwähnt wurde.

Nur "weil man das jetzt eben so macht und fertig" werde ich bestimmt nicht nach TDD entwicklen. Ich würde auch keine rosa Flipp-Flopps mit Keilabsätzen tragen, auch wenn das die angesagte Herren-Sommemode werden sollte.

Ich wehre mich einfach gegen diese "Mach es so, dann wirst Du Erfolg haben!" Ideologie.

Ich habe nur gute Erfahrungen mit Unit-Tests gemacht.
Und man schreibt den Code doch etwas anders. Flexibler.

Das deckt sich mit den anderen Aussagen, über implizite Verbesserungen in der Archtiktur, die automatisch gemacht werden, um testbaren Code zu erzeugen. Das ist in Ordnung, warum nicht. Dann hat man Tests + bessere Architketur.
Allerdings lassen sich Verbesserungen in der Architektur auch durch entsprechende Konzepte und Konventionen im Entwickler-Team erreichen. Auch ersetzen Tests nicht die Notwendigkeit sich bei einem projekt über Software-Architektur Gedaken zu machen.

Ich behaupt einfach mal dass Unit-Tests ab einem bestimmten Projektumfang IMMER den Zeitaufwand hinten raus reduzieren.

Kannst Du das auch beweisen? Um wie viel Prozent haben Bugs und Support-Anfragen seit der Einführung von automatischen Tests zurückgegangen? Hast Du (oder jemand anders) das mal gemessen?
Haben die Tests wirklich eine nennenswerte Verbesserung im Verleich zum Aufwand gebracht?

Und dass der produktive Code durch die Unittests besser wird, ist IMHO auch Tastache.

Das ist nur eine rethorische Killerphrase. "Besser" ist sehr schwammig und allgemein. Wenn der Einsatz von Tests sich vorteilhaft auf das Endergebnis auswirkt, dann muss man dies messen können. Ansonsten ist es nur "ein gutes Gefühl". Selbst wenn es dem Entwicklerteam nur ein gutes Gefühl gibt, wüssten dessen positive Auswirkungen (Motivation, Mut zu Refaktorisierungen, etc.) sich auch wieder messbar niederschlagen. Vorrausgesetzt, man kann Änderungen im Gesamtergebnis eindeutig auf die Tests zurückführen. Eine Reduzierung der Bugs könnte auch die kürzliche Gehaltserhöhung der Entwickler oder die neuen ruhigen und klimatisierten Büros herbeigeführt haben.

Deshalb die Frage: Kennt jemand eine unabhängige Studie, welche die effektiven Verbesserungen in Projekten durch automatische Tests gemessen hat?
Bitte keine Fallstudien, in denen einfach verschiedene Leute interviewed wurden und sagen, dass sie jetzt alle glücklicher sind.

Versteht mich bitte nicht falsch. Ich erkenne die Vorteile von automatischen Tests voll und ganz an. Aber ich denke, dass der Aufwand den Nutzen am Ende übersteigt.

Vielleicht sind automatische Tests auch nur in bestimmten Szenarien wirklich rentabel.
Ich kann mir z.B. gut vorstellen, dass Tests in einem Team mit hoher Fluktuationsrate wesentlich mehr bringen, als in einem eingespielten Team. Wenn ich mir vorstelle, dass Teile eines Projekts vielleicht mittels Offshore-Outsourcing ausgelagert werden, dann beginne ich Tests immer interessater zu finden.

Wenn ich aber weder hohe Fluktuation im Team noch Outsourcing habe, dann finde ich die Tests wiederum nicht mehr sonderlich interessant. Ich darf meine Situation deshalb nicht verallgemeinern. Aber andere dürfen das ebensowenig.

2.921 Beiträge seit 2005
vor 13 Jahren

Zitat:

Versteht mich bitte nicht falsch...

Unit Testing - Wikipedia

Ich verstehe Dich schon richtig, denke ich. Du möchtest einfach einen stichhaltigen Beweis WAS BRINGEN UNITTESTS?

Im Abschnitt "Overview" auf der im Link genannten Seite heißt es:

A study conducted by NIST in 2002 reports that software bugs cost the U.S. economy $59.5 billion annually. More than a third of this cost could be avoided if better software testing was performed.[3]

Ich denke das könnte interessant sein:

Nist Report

und auch dieser Link:

Economical Analysis

EDIT: @Rainbird: Wir könnten auch selber eine Studie starten, mit 2 unabhängigen Gruppen (Das können auch einzelne Entwickler sein)

Eine Gruppe benutzt Unit Tests mit allen möglichen Vorteilen. Die andere nicht.

Was passiert?

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

2.921 Beiträge seit 2005
vor 13 Jahren

noch einen gefunden:

Economic Impact...

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

71 Beiträge seit 2010
vor 13 Jahren

Nur "weil man das jetzt eben so macht und fertig" werde ich bestimmt nicht nach TDD entwicklen. Ich würde auch keine rosa Flipp-Flopps mit Keilabsätzen tragen, auch wenn das die angesagte Herren-Sommemode werden sollte.

Rosa Flipp-Flopps vs TDD? Ob das ein passender Vergleich ist? Hm...

Aber natürlich glaube ich schon lange nicht mehr daran, dass Erkenntnis irgendjmd zu einer Veränderung bewegen könnte. Die Welt ist schließlich voll von Gegenbeispielen. Und die Psychologie voll von Beschreibungen von Abwehrmaßnahmen gegen Erkenntnis.

Veränderung bedeutet Mühe. Veränderung bedeutet Unsicherheit. Veränderung bedeutet womöglich Anerkenntnis von etwas, was von draußen kommt, gar von etwas, dass einem "aufgedrückt" wurde. Das und weiteres spricht oft gegen die Akzeptanz von Erkenntnis - die man nicht selbst durch Erfahrung gewonnen hat.

Deshalb kann ich nur allen raten, die skeptisch bzgl. autom. Tests sind: probiert es aus. Aber richtig! NUnit runterladen und mal eine [TestFixture] aufsetzen, ist nicht genug. Bei autom. Tests geht es nicht um Technologie. Die ist trivial. Es geht um "programmer life style" 😉 Es geht um Gewohnheit, grundlegende Denkweise. Und die "umzuprogrammieren" schafft man nicht in 2 Stündchen am Nachmittag, zu denen man sich mal prügelt, um endlich mal ein wenig autom. Tests auszutesten.

Trotz meiner Skepsis, dass Erkenntnisse der Branche etwas bringen, hier ein paar Hinweise auf Forschungsergebnisse zum Thema TDD:

http://haacked.com/archive/2008/01/22/research-supports-the-effectiveness-of-tdd.aspx

http://jamesshore.com/Blog/AoA-Correction-Test-Driven-Development.html

http://weblogs.asp.net/mhawley/archive/2004/04/15/114005.aspx

http://www.infoq.com/news/2009/03/TDD-Improves-Quality

Allerdings lassen sich Verbesserungen in der Architektur auch durch entsprechende Konzepte und Konventionen im Entwickler-Team erreichen. Auch ersetzen Tests nicht die Notwendigkeit sich bei einem projekt über Software-Architektur Gedaken zu machen.

Beides ist natürlich wahr. So ganz grundsätzlich. Bewusste Architekturplanung hat jedoch ein Ende auf irgendeiner recht groben Granularitätsebene. Und muss auch durchaus abgebrochen werden, um nicht in ein BDUF zu verfallen. Was dann? Dann hilft TDD weiter. TDD strukturiert also sozusagen unterhalb des Radars von Architektur.

Kannst Du das auch beweisen? Um wie viel Prozent haben Bugs und Support-Anfragen seit der Einführung von automatischen Tests zurückgegangen? Hast Du (oder jemand anders) das mal gemessen?
Haben die Tests wirklich eine nennenswerte Verbesserung im Verleich zum Aufwand gebracht?

Das sind völig valide Fragen. Und nicht umsonst gibt es einen CCD Baustein, der zur Messung von Fehlern aufruft.

Dennoch stelle ich mal die Frage dagegen: Ist sich dein Unternehmen eigentlich heute (!) bewusst, welche Arten von Fehlern in welcher Frequenz gemeldet werden und wie lange ihre Beseitigung benötigt? Denn nur wenn du das heute erhebst, hast du einen Vergleichswert. Wieviel Aufwand fließt heute in eure manuellen Tests? Bitte messen. Wieviel Aufwand fließt in die Behebung von Regressionsfehlern? Bitte messen.

Aber ich denke, dass der Aufwand den Nutzen am Ende übersteigt.

Definiere Nutzen.

S
8.746 Beiträge seit 2005
vor 13 Jahren

Mein kleiner Tipp für all diejenigen, die mit Unit-Tests anfangen möchten: Legt euch ein Tool für Code-Coverage zu. Es fördert den "sportlichen Ehrgeiz" (intrinsische Motivationen sind immer wichtig) und gibt einem das Gefühl, wann es "genug" ist.

Rainbird Themenstarter:in
3.728 Beiträge seit 2005
vor 13 Jahren
Analyse

@dr4g0n76: Danke für die Links!

@ralfw: Ebenfalls, danke für die Links!

Ist sich dein Unternehmen eigentlich heute (!) bewusst, welche Arten von Fehlern in welcher Frequenz gemeldet werden und wie lange ihre Beseitigung benötigt? Denn nur wenn du das heute erhebst, hast du einen Vergleichswert. Wieviel Aufwand fließt heute in eure manuellen Tests? Bitte messen. Wieviel Aufwand fließt in die Behebung von Regressionsfehlern? Bitte messen.

Ja natürlich. Alle Fehler werden in einem Bugtracking-System erfasst. Auch die Lösungen dazu werden erfasst. Die Zeitpunkte, wann was bemerkt und wann was getan wurde und wann welcher Bug nachweislich gelöst wurde, werden dabei auch erfasst. Dies ermöglicht zuverlässige Messung und Auswertung der Daten.

Definiere Nutzen.

Verminderung der Häufigkeit des Auftretens von Fehlern (Bugs).
Reduzierung der Anrufe wegen Bugs bei der EDV-Hotline.
Reduzierung von Kosten, die durch Fehler entstehen (z.B. Buchungsfehler aufgrund von fehlerhaftem Programmcode).
Reduzierung von Zeit/Kosten für die Pflege und Weiterentwicklung vorhandener Software (Stichwort Refaktorisierung).

185 Beiträge seit 2005
vor 13 Jahren

hallo,

natürlich ist das jetzt keine Studie oder ein wissenschaftlicher Beweis - aus bisheriger Erfahrung kann ich jedoch sagen:

  • In einem Vorgängerprojekt, in dem es wenige und vor allem "weniger gute" automatische Tests gibt, habe ich ein ungutes Gefühl, wenn ich etwas ändern muss.
  • Das Testen nach Änderungen, ob noch alles funktioniert, ist weit aufwändiger.
  • Die Architektur ist generell schwer zu testen d.h. nachträglich Tests zu schreiben ist nicht so einfach.

Zum letzten Punkt muss man ergänzen: Natürlich lernt man dazu und macht vieles beim "2. Versuch" besser. Der persönliche Nutzen ist jedenfalls, dass ich im aktuellen Projekt, wo es mehr automatische Tests gibt, es einfacher/sicherer finde, wenn etwas geändert werden muss.
Das reicht mir als Argumentation für automatische Tests + ich denke, jeder der das selbst erlebt hat, dem geht es ebenso. Soll heißen: Man macht sich als Entwickler das eigene Leben leichter. 😉

Das heißt jetzt natürlich nicht, dass es nicht trotzdem Bugs gibt - wenn das jedoch der Fall ist, wird dieser behoben + gleich ein Test dafür geschrieben, der beweist, dass der Bug behoben ist. So sieht man es auch z.B. bei nHibernate, wo es neben den allgemeinen Tests noch Tests für "Fixtures" gibt, diese haben die selbe Nummer wie im Bugtracking System und so gibt es dann einen Zusammenhang zwischen Bug + Test, der dessen Fix beweist.

71 Beiträge seit 2010
vor 13 Jahren

Verminderung der Häufigkeit des Auftretens von Fehlern (Bugs).
Reduzierung der Anrufe wegen Bugs bei der EDV-Hotline.
Reduzierung von Kosten, die durch Fehler entstehen (z.B. Buchungsfehler aufgrund von fehlerhaftem Programmcode).
Reduzierung von Zeit/Kosten für die Pflege und Weiterentwicklung vorhandener Software (Stichwort Refaktorisierung).

Wie häufig treten Bugs heute auf? Sagen wir mal, das messt ihr heute.

Führt ihr Daten darüber, welche Kosten heute durch Fehler entstehen, z.B. wieviel kostet ein Buchungsfehler den Kunden (oder euch)?

Messt ihr heute die Zeit, die ihr in Pflege/Refaktorisierungen steckt? (Die stehen nicht im Bug Tracker 😉

M
164 Beiträge seit 2009
vor 13 Jahren

Vorteil für ein gut getestetes System: Man kann am Abend nach Hause gehen und es lässt einen besser schlafen. Man weiss, dass alle Tests fehlerfrei durchlaufen und somit keine Fehler zu erwarten sind.

Wenn im Markt ein Fehler auftritt, kann dieser einfach mit einem Test nachgebildet werden. Dann wird der Code korrigiert und der Test erfüllt => Dieser Bug wird nie mehr auftreten, da es dafür jetzt einen Test gibt.

1.820 Beiträge seit 2005
vor 13 Jahren

Hallo!

Ich beschäftige mich z.Zt. eher noch nebenbei mit dem Thema, denke aber, dass Unit-Tests durchaus ihre Daseinsberechtigung haben. Bestimmt gibt es auch Ausnahmen, aber die gibt es fast immer.

Allerdings ist auch wichtig. bei Unit-Tests die Testabdeckung zu berücksichtigen. Unit-tests bringen nichts, wenn zwar alle Tests positiv ablaufen, sie aber nur 10% des Gesamtsystems abdecken. Hier liegt evtl. die größte "Gefahr" von Unit-Tests, dass das Ergebnis unabhängig der Abdeckung betrachtet wird.

Nobody is perfect. I'm sad, i'm not nobody 🙁

F
60 Beiträge seit 2010
vor 13 Jahren

man sollte wohl zwischen einfachen unit tests und tdd differenzieren. natürlich bringen unit tests wenig bis nichts, wenn die coverage im niedrigen zweistelligen bereich liegt. allerdings kann dies bei konsequentem tdd nicht passieren.

D
500 Beiträge seit 2007
vor 13 Jahren

Ich finde es interessant wie vehement hier doch ueber TDD diskutiert wird.

Wir sind in unserem Unternehmen gerade an einer Stelle angelangt in der ein Umbruch stattfindet und wir vermehrt auf TDD setzen. Was ich feststellen kann, ist dass einige theoretisch TDD gut finden, allerdings selber eher zaghaft bis gar nicht TD-entwickeln und einige es noch gar nicht anwenden. Sie haben gemein, dass Sie als Argument anbringen, dass TDD die Entwicklung verlangsamt und "Mal eben ein Bugfix am Framework" nicht durchgefuehrt werden kann. Sicherlich verlangsamt TDD anfangs die Entwicklung, denn, wie Ralph bereits erwaehnt hat, bedeutet TDD ein Umdenken, ein anderes, nicht vertrautes Vorgehen sich aneignen, was fuer Unbehagen sorgt.
Aber es gibt auch Entwickler, die mittels intrinsischer Motivation sich auf Unit Test, Insolations-Frameworks, TDD und Co. einlassen und schnell die Vorteile sehen.
Ich kann aus eigener Erfahrung sagen, dass man sich auf TDD einfach mal einlassen sollte und zwar ueber die Schwelle einfacher TextFixtures hinaus. Einlassen deshalb, weil es genug Leute gibt, die viel Zeit haben sich mit solchen Dingen zu beschaeftigen und ein gutes Urteil abgeben koennen. Warum diesen nicht mal vertrauen und selber in einem Feldtest ausprobieren. Nach einiger Zeit (das kann gut mal ein Monat sein) stellt sich ein gewisser AHA-Effekt ein und das ist der Punkt, der erreicht werden muss. Fuer mich waren AHA-Effekte:

"...Wow, den Fehler haette ich glatt uebersehen, wenn ich nicht den Test dafuer geschrieben haette.." (und das nicht nur einmal)

"...das Interface ist doch ein wenig zu kompiziert geschnitten, sodass ich es ueberarbeiten muss..."

"...ich kann beruhigt Aenderungen vornehmen, weil ich nicht viel kaputt machen kann, obwohl den Code ein Kollege geschrieben hat..."

"...ich brauche erst einmal meine gesamte App nicht mehr zu starten, um gewisse Logik nur kurz zu testen. Das Entwickeln geht viel schneller von der Hand..."

Testgetrieben vorzugehen sehe ich als unabhaengig von der Teamgroesse, egal wie "kommunikativ" jemand ist (wie in einem Vorpost als Argument gegen TDD zu lesen war). Selbst ich weiss manchmal nach ein paar Wochen nicht mehr genau, war an dieser oder jenen Stelle im Code explizit gemacht wurde und ich denke, dass ich nicht der einizige bin, der vor so einem Problem steht. Und da helfen UnitTests ungemein den Code wieder zu verstehen und auch das Gefuehl zu geben, dass ich andere Dinge nicht zerstoere, vor allem bei grossen Projekten, die man als Durchschnittsmensch aufgrund der Komplexitaet nicht mehr fassen kann. Und da ist TDD genau das richtige Mittel, denn hinterher schreibt man die Test nicht mehr oder nur noch sehr ungern und macht diese nur oberflaechlich, sodass man sie gleich weglassen kann.

Gruss,
DaMoe

2.921 Beiträge seit 2005
vor 13 Jahren

@Rainbird: Um nochmal auf Deine Fragen zu Beginn zurückzukommen:

wenn man der Fachpresse glaubt, dann gehören Unit-Tests zum Guten Ton in der Branche und sollten quasi eine Selbstverständlichkeit sein. Ist das wirklich so?

Ja, es ist so dass diese eine Selbstverständlichkeit SEIN SOLLTEN. (Aber nicht SIND).

Ich selbst habe Zeifel am Nutzen von Unit-Tests, wenn man den Aufand ins Verhältnis setzt...

Ich nenn mal ein Beispiel. Stell Dir vor Du hast ein GUI geschrieben. Es hat ein paar Methoden und macht was Du willst.

Jetzt willst Du es per Unit-Tests testen. Mußt Du etwas umschreiben, damit es testbar wird, weil vielleicht die benötigte Granularität fehlt?
Oder läßt es sich so gar nicht testen?

z.B. sind Methoden direkt abrufbar oder ist vielleicht mancher Code einfach nur direkt in den EventHandler programmiert?

Ich glaube anhand einiger solcher Fragen sieht man ob etwas umgeschrieben werden muss.

So und jetzt nochmal zurück:

Führt der sachgemäße Einsatz von Unit-Tests tatsächlich zu qualitativ hochwertiger Software?

Was geht wohl schneller, Code a little test a little and then test a little more (Bugfixes)
oder gleich "aufs Knöpfchen drücken" und sich vom Unittest aussagen lassen, wo etwas fehlgeschlagen ist?

So gesehen kann man zumindest behaupten:

Es führt zu weniger Fehler in derselben Zeit und das auf jeden Fall bei längerfristigen Projekten. Und weniger Fehler machen zumindest einen Teil der Qualität aus. Weniger Zeit heißt doch dass die Produktivität gesteigert wird.

Aber wie Du auch schon erwähntest:

Dir fehlt eben immer noch eine empirische Studie.

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

S
489 Beiträge seit 2007
vor 13 Jahren

Legt euch ein Tool für Code-Coverage zu. Es fördert den "sportlichen Ehrgeiz" (intrinsische Motivationen sind immer wichtig) und gibt einem das Gefühl, wann es "genug" ist.

Oh ja, das tut es in der Tat. 😁

Rainbird Themenstarter:in
3.728 Beiträge seit 2005
vor 13 Jahren
Empirische Studie

Hallo zusammen,

ich habe auch noch eine interessante Studie von Microsoft Research zu Thema TDD gefunden: http://research.microsoft.com/en-us/projects/esm/fp17288-bhat.pdf

Wenn ich das und die Aussagen der Links von Ralf und dr4g0n76 auf harte Zahlen reduziere, komme ich dabei auf folgende Ergebnisse:

Durch Einsatz von TDD kann die Anzahl der Bugs um das 2-5 fache reduziert werden. Statt 50 Bugs könnten das dann also nur 25 oder sogar nur 10 Bugs sein, wenn TDD eingesetzt wird. Wie hoch die Ausbeute ausfällt hängt natürlich vom einzelnen Projekt ab. Das war auch in den verschiedenen Studien teilweise sehr unterschiedlich. Aber selbst wenn man passimistisch ist, dann ist die Halbierung der Fehler schon ein Wort.

Dem Gegenüber steht allerdings eine gemessene Verlängerung der Entwicklungszeit (und damit auch höhere Kosten) von 15-35%.

Ob TDD sich "kalkulatorisch" rentiert, hängt also davon ab, wie viel das Doppelte bis Fünffache an Fehlern letztendlich kostet. Wenn die gegenüber TDD überzähligen Fehler weniger als 15% der Gesamtentwicklungskosten an zusätzlichem Aufwand produzieren, dann ist es billiger, ohne TDD zu entwickeln. Wenn die Fehler allerdings mehr als diese 15% zusätzlich kosten, dann ist TDD eindeutig "günstiger".

Jetzt habe ich einen Überblick, was die höhere - durch Tests erreichte - Qualität kostet, bzw. in wie weit sie sogar insgesamt günstiger sein kann. Da muss ich nun erst eine Nacht drüber schlafen.

71 Beiträge seit 2010
vor 13 Jahren

@Rainbird: Unit Tests bzw. autom. Testen bzw. TDD hat nicht (!) nur den Zweck, irgendwie Fehler früher zu finden. Das kann ich gar nicht genug betonen.

Natürlich es aber das, was Studien irgendwie am besten messen können. Also messen sie es. Am Ende ist das jedoch eine Reduktion.

Die Liste der Vorteile, die TDD et al. bringt, ist länger. Wenn du also hergehst und nun versuchst auszurechnen, ob sich TDD vom ROI her lohnt, weil du genau weißt, wieviel dich deine Fehler heute kosten und kommst darauf, dass TDD et al. die Entwicklung 13,65% teurer machen würden und deshalb unrentabel wäre, dann hast du TDD et al. leider nicht richtig verstanden und tust ihnen Unrecht.

Ich bleibe dabei: Dich werden keine Zahlen überzeugen. Du wirst es dir immer so hinrechnen können, dass TDD et al. zu teuer sind.

Dich kann nur eines überzeugen: Erfahrung. Die aber kannst du nicht an einem Woende kriegen. Für die müsstest du dir 1-2 Monate Zeit nehmen und dich ganz auf TDD et al. einlassen.

Du siehst es hier im Forum: Die große Mehrheit der Leute setzt auf autom. Tests und bezeugt, dass das Vorteile hat. Das beeinflusst deine Meinung nicht. Weder also Beispiele von anderen noch Zahlen bringen dir etwas. Wir reden hier über Gewohnheiten und Glaubenssätze. Und gegen die kommen nur andere Erfahrungen an.

Aber du musst dir das natürlich nicht antun. Niemand muss TDD et al. einsetzen. Wenn du zufrieden bist, dann lass es.

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Rainbird,

Wenn die gegenüber TDD überzähligen Fehler weniger als 15% der Gesamtentwicklungskosten an zusätzlichem Aufwand produzieren, dann ist es billiger, ohne TDD zu entwickeln.

das ist in zweifacher Hinsicht etwas zu kurz gegriffen. Zum einen berücksichtigt es nicht die volkswirtschaftliche Komponente. Denn durch einen Fehler entsteht ja auch dem Kunden ein Schaden oder zumindest ein Aufwand. Sich da auf den Standpunkt zu stellen, dass das ja keine Kosten sind, die die eigene Firma tragen muss, mag betriebswirtschaftlich richtig sein, aber es wäre schade, in so engen Grenzen zu denken. Zumal - das wäre mein zweiter Punkt - die Kosten durch Fehler für den Kunden natürlich eine Rolle spielen und sicher auch in die Entscheidung für oder gegen ein Produkt mit einfließen. Und spätestens, wenn sich aufgrund vieler Fehler Kunden von der eigenen Firma abwenden, schlägt das doch wieder in den betriebswirtschaftlichen Bereich durch - diesmal als entgangene Einnahmen, die man aber auch als Kosten rechnen kann.

Zu dem (Zwischen)Ergebnis der Umfrage noch ein Wort:

Es setzen über 80% der Leute Unit-Tests ein (weil sie die Vorteile sehen oder sogar aus voller Überzeugung) oder haben sich fest vorgenommen, das zu tun. Dagegen stehen weniger als 20%, die keine Vorteile sehen oder sich einfach noch nicht mit dem Thema beschäftigt haben. Und keiner muss Unit-Tests einsetzen, ohne Vorteile darin zu sehen.

Zwar ist es richtig, dass sich auch eine große Mehrheit irren kann, aber wenn dir die Meinung der Leute egal wäre, hättest du sie ja wohl nicht danach gefragt. Das Ergebnis der Umfrage ist jedenfalls ausgesprochen eindeutig.

herbivore

185 Beiträge seit 2005
vor 13 Jahren

hallo,

man sollte wohl auch "einrechnen": Wie schnell kann ich Änderungen (die es immer gibt) oder Erweiterungen durch neue Anforderungen implementieren und sicher sein, bestehende Funktionalität nicht zu gefährden/brechen.

Beispiel: Erweiterung x dauert 5 MT.
Danach müsste ich genaugenommen das gesamte Programm nochmal testen, Aufwand z.B. 10MT
Durch automatische Tests reduziert sich der manuelle Testaufwand auf z.B. 5 MT.

D.h. beim Implementieren der Erweiterung x konnte ich durch automatische Test 5 MT einsparen. Nun ist noch die Frage, wie viele Erweiterungen/Änderungen es an meiner Software so geben wird.

71 Beiträge seit 2010
vor 13 Jahren

Betriebswirtschaftliche Sicht, volkswirtschaftliche Auswirkung, eindeutiges Umfrageergebnis... das ist alles richtig... aber es wird Rainbird und anderen wenig helfen. Es geht einfach nicht um "Objektivität" oder "harte Fakten".

Das macht das Thema so nervig. Andererseits macht es das Thema aber auch interessant. Denn ich würde gern eruieren, was das Wurzelproblem bei den heutigen "Unit Test Verweigerern" ist. Ist natürlich schwer rauszufinden. Die selbst sind ja quasi per definitionem nicht in der Lage das zu reflektieren.

Naja... sei´s drum. Beim Testen sehe ich zu meiner Freude, dass es auf die Branche gerechnet eigentlich kein großes Thema ist. Es tun noch nicht alle, aber das liegt eher nicht an Unverständnis oder Unwille, sondern am Umfeld.

Wir können uns daher darauf konzentieren zu überlegen, wie das Umfeld für diejenigen noch verändert werden kann, dass sie es tun können. Die anderen, die Unwilligen, sind eine schrumpfende Randgruppe.

6.911 Beiträge seit 2009
vor 13 Jahren

Hallo Ralf,

Denn ich würde gern eruieren, was das Wurzelproblem bei den heutigen "Unit Test Verweigerern" ist.

Wenn ich mich in die Zeit zurückversetze als ich C# programmieren lernte verwendete ich zu Beginn keine Tests*.
Der Grund: Zu viel Neues auf einmal und die Scheu sich mit dem Thema (automatische) Tests auseinander zusetzen. Das hört sich ja kompliziert an und ist mit Aufwand verbunden.

Ich kann mir gut vorstellen dass das ein "Pauschalgrund" ist.

Man sollte sich jedoch über das Thema trauen denn es ist gar nicht so kompliziert wie es sich (anfänglich) anhört.

* jetzt wird schon getestet 😉

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

1.820 Beiträge seit 2005
vor 13 Jahren

Hallo!

@ralfw:

Denn ich würde gern eruieren, was das Wurzelproblem bei den heutigen "Unit Test Verweigerern" ist

Ich spreche da jetzt mal aus eigener Sicht:
Ich als Programmierer bin faul, deshalb schreibe ich ja Programme, die eine bestimmte Arbeit erleichtern bzw. automatisieren soll (manchmal mache ich mir dabei allerdings auch mehr Arbeit als ohne 8o weil ich dann auch oft entgegen den CCD-Prinzipien KISS und YAGNI entwickle).

Daher habe ich mich lange dagegen gesträubt, erstmal Tests zu schreiben, ehe die eigentliche Funktion implementiert werden konnte.

So langsam setzt sich bei mir aber die Erkenntnis durch, dass man langfristig Zeit gewinnt und Aufwand reduziert, weil Fehler schneller eingegrenzt und behoben werden konnten.

Ein weiterer Hinderungsgrund könnte sein, dass viele einfach nicht wissen, wie Sie Unit-Tests ausführen sollen, bzgl. den zusätzlichen Aufwand scheuen. Und nicht jeder wird auch gleich eine vollständige CI-Umgebung parat haben, welche solche Aufgaben automatisch erledigt.

Nobody is perfect. I'm sad, i'm not nobody 🙁

2.921 Beiträge seit 2005
vor 13 Jahren

@Ralfw:

Betriebswirtschaftliche Sicht, volkswirtschaftliche Auswirkung, eindeutiges Umfrageergebnis... das ist alles richtig... aber es wird Rainbird und anderen wenig helfen. Es geht einfach nicht um "Objektivität" oder "harte Fakten".

Es wird ihm vielleicht nicht direkt helfen, aber die Nachfrage Rainbirds nach einer Studie - mit Ergebnis - würde ich doch als in diese Richtung gehend werten.

Das macht das Thema so nervig. Andererseits macht es das Thema aber auch interessant. Denn ich würde gern eruieren, was das Wurzelproblem bei den heutigen "Unit Test Verweigerern" ist. Ist natürlich schwer rauszufinden. Die selbst sind ja quasi per definitionem nicht in der Lage das zu reflektieren.

Hier ein paar Aussagen, die ich bisher aus mehreren Firmen gehört habe:

"Automatische Tests? Unit-Tests? Die muss man selber schreiben? Das kostet zu viel Zeit und verzögert das Projekt"

"Bis ich das alles eingerichtet habe...Puh! Was das Zeit kostet..."

"Was bringt das?"

Wie schon erwähnt wurde: Ablehnung neuem Gegenüber, Angst vor neuem, vielleicht auch ein wenig Zurückhaltung, um es mal nicht Faulheit zu nennen.

Naja... sei´s drum. Beim Testen sehe ich zu meiner Freude, dass es auf die Branche gerechnet eigentlich kein großes Thema ist. Es tun noch nicht alle, aber das liegt eher nicht an Unverständnis oder Unwille, sondern am Umfeld.

Wir können uns daher darauf konzentieren zu überlegen, wie das Umfeld für diejenigen noch verändert werden kann, dass sie es tun können. Die anderen, die Unwilligen, sind eine schrumpfende Randgruppe.

Damit stimme ich überein. Oder anders formuliert: Immer mehr widmen sich dem Thema UnitTests und es wird geprüft, was bringt es mir und dem Projekt und damit letztendlich der Firma.

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

Gelöschter Account
vor 13 Jahren

ich finde, das das verlangen nach harten zahlen und studien absolut berechtigt und legitim ist. immerhin braucht man solche zum argumentieren und entscheiden. bauchgefühle sind in BWL sprache nur selten erwünscht.

und das messen der zeit bei einem selber usw.. was z.b. von einigen verlangt wird, finde ich absolut unnötig und sinnfrei. kein chef oder entwickler wird sich für unittests entscheiden, weil m user auf mycsharp geschrieben haben, das sie n minuten/stunden/tage/jahre gespart haben.
zudem ist sowas weder wissenschaftlich noch repräsentativ....

2.921 Beiträge seit 2005
vor 13 Jahren

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

Rainbird Themenstarter:in
3.728 Beiträge seit 2005
vor 13 Jahren

Unit Tests bzw. autom. Testen bzw. TDD hat nicht (!) nur den Zweck, irgendwie Fehler früher zu finden. Das kann ich gar nicht genug betonen.

Das ist mittlerweile auch bei mir angekommen.

Die Liste der Vorteile, die TDD et al. bringt, ist länger. Wenn du also hergehst und nun versuchst auszurechnen, ob sich TDD vom ROI her lohnt, weil du genau weißt, wieviel dich deine Fehler heute kosten und kommst darauf, dass TDD et al. die Entwicklung 13,65% teurer machen würden und deshalb unrentabel wäre, dann hast du TDD et al. leider nicht richtig verstanden und tust ihnen Unrecht.

Ich bleibe dabei: Dich werden keine Zahlen überzeugen. Du wirst es dir immer so hinrechnen können, dass TDD et al. zu teuer sind.

Du schätzt mich da völlig falsch ein. Ich wollte TDD damit nicht auf die harten Zahlen reduzieren. Aber die harten Zahlen müssen trotzdem sein, um objektiv zu beweisen, ob TDD auch tatsächlich etwas bringt. Ich weiss jetzt, auf wieviel zusätzliche Entwicklungszeit ich mich einstellen muss und was - jetzt mal nur auf die Bugs bezogen - ich damit erreichen kann (pessimistisch gesehen, wäre das die Halbierung der Bugs). Wenn ich dazu noch zusätzliche "Bonus-Leistungen" bekomme, dann könnte sich die Testerei vielleicht doch lohnen.

Für die müsstest du dir 1-2 Monate Zeit nehmen und dich ganz auf TDD et al. einlassen. Das würde mich bestimmt zum absoluten Test-Experten machen, aber 1-2 Monate Zeit nehmen ist - zumindest momentan - utopisch. Es werden wohl eher 6-12 Monate werden, in denen ich mich "nebenher" und bröckchenweise in das Thema reinarbeite.

Du siehst es hier im Forum: Die große Mehrheit der Leute setzt auf autom. Tests und bezeugt, dass das Vorteile hat. Das beeinflusst deine Meinung nicht. Weder also Beispiele von anderen noch Zahlen bringen dir etwas. Wir reden hier über Gewohnheiten und Glaubenssätze. Und gegen die kommen nur andere Erfahrungen an.

Ich würde schon sagen, dass mich die Meinungen der Leute hier beinflussen. Ich mache ja keine Umfrage, um die Ergebnisse am Ende einfach zu ignorieren. Das bisherige Umfrageergebnis hat meine Vorahnungen bestätigt. Es gibt eine ganze Menge Leute, die noch keine Tests machen, aber sich bereits mit dem Thema befassen und irgendwann auch automatische Tests machen werden. Die machen das bestimmt nicht alle nur, weil sie irgendwo gelesen haben, dass automatische Tests jetzt Hipp und Cool sind. Dieser Thread hier ist voll von sachlichen Argumenten für automatische Tests. Auf der Gegenseite sieht es dagegen mau aus. Wenn ich mir die Ohren zuhalten wollte, dann würde ich doch keine Fragen stellen, oder?

Wenn du zufrieden bist, dann lass es.

Ich bin eigentlich schon zufrieden. Aber vielleicht bin ich noch viel zufriedener, wenn sich meine Bugs halbieren.

um einen berücksichtigt es nicht die volkswirtschaftliche Komponente. Denn durch einen Fehler entsteht ja auch dem Kunden ein Schaden oder zumindest ein Aufwand. Sich da auf den Standpunkt zu stellen, dass das ja keine Kosten sind, die die eigene Firma tragen muss, mag betriebswirtschaftlich richtig sein, aber es wäre schade, in so engen Grenzen zu denken. Zumal - das wäre mein zweiter Punkt - die Kosten durch Fehler für den Kunden natürlich eine Rolle spielen und sicher auch in die Entscheidung für oder gegen ein Produkt mit einfließen.

Natürlich darf man das alles nicht außer Acht lassen. Da sich das aber schlecht messen lässt, schaue ich erst mal auf das, was sich messen lässt. Die 15% + 5% Angstzuschlag bei Halbierung der Bugs sind okay. Also macht es Sinn, sich näher damit zu beschäftigen. Die "weichen" Vorteile kann ich dann erst durch eigene Erfahrungen überprüfen. Zuerst wollte ich aber wissen, ob ich die Zeit überhaupt investieren will, um diese Erfahrungen zu machen. Das ist nun geklärt.

5.742 Beiträge seit 2007
vor 13 Jahren

Gestern bin ich auf eine Art "Lager" der nicht TDDler gestoßen 😁yield through: TDD without the T.
Zwar nicht ganz meine Meinung, aber in manchen Punkten durchaus nachvollziehbar.

199 Beiträge seit 2006
vor 13 Jahren

Mir fehlt da die Antwortmöglichkeit "Situationsbedingt". Meiner Meinung nach wird es häufig übertrieben mit den ganzen Tests. Auf der anderen Seite gibt es aber definitiv Situationen bei denen UnitTests wärmstens zu empfehlen sind. Man muss das irgendwie immer selber abschätzen, ob sich der Aufwand lohnt.

Einfaches abstraktes Beispiel:
Bei einer Addition von zwei Integern brauche ich keinen UnitTest, weil das immer gelingen wird. Dagegen bei einer Division ist es eher zu empfehlen, da bei einer Division durch 0 ein Fehler auftreten kann und dadurch die Anwendung nicht ins Chaos stürzen soll.

Wirklich helfen tun einem UnitTests aber nur, wenn sie auch kontinuierlich gepflegt und erweitert werden, so dass sie wirklich das gesamte Spektrum abdecken. Diesen Aufwand darf man auf keinen Fall vergessen.

Ich muss zugeben, dass ich fast nie Tests schreibe. Lediglich bei komplexen Algorithmen greife ich darauf zurück um bei jeder Änderung daran sicherstellen zu können, dass alle Eventualitäten abgefangen sind.

6.911 Beiträge seit 2009
vor 13 Jahren

Hallo,

Bei einer Addition von zwei Integern brauche ich keinen UnitTest, weil das immer gelingen wird

Da kann eine möglcihe Falle lauern. Wenn zB int.MaxValue + int.MaxValue gerechnet wird kommt eine negatives Ergebnis heraus (-2) - das könnte mit Test "aufgedeckt" werden 😉

Also selbst bei trivialen Aufgaben lohnt es sich. Hier zB durch Assert.IsTrue(result > 0).

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Mossi,

Bei einer Addition von zwei Integern brauche ich keinen UnitTest, weil das immer gelingen wird.

du wolltest demonstrieren, dass Tests nicht überall nötig sind, hast am das genaue Gegenteil gezeigt. Durch den begrenzten Wertebereich von Integer-Werten kann eine Addition eben doch schiefgehen. Das ist ein Fall der sogar sehr häufig übersehen wird. Mit geeigneten Tests kann man ihn aufspüren. Da du mit deinem Beispiel gezeigt hast, dass auch in scheinbar trivialem Fehlerpotenzial steckt, sollte man eben doch immer Tests schreiben.

herbivore

199 Beiträge seit 2006
vor 13 Jahren

Aber genau darin liegt der Hund begraben. Man kann lediglich Sachen testen an die man selber denkt. Und wenn man daran denkt, kann und muss man diese Fälle ohnehin bereits bei der Realisierung abfangen. Ein Assert würde also schon gar nicht mehr anspringen, weil ich den Fall bereits bei der Realisierung abgefangen habe.

In diesem einfachen Beispiel hätte ich zum Beispiel einfach einen Mock geschrieben, der an die Methode ein paar für mich realistische Werte geschickt hätte. Darunter wäre aber eben nicht MinValue und/oder MaxValue gewesen, weil ich daran nicht gedacht hätte, dass es diese Constanten (sind glaub ich Constanten, oder?) gibt. Damit wäre ich durch die Tests nicht in diesen Fehler gelaufen, woraus folgt, dass der Test sinnlos gewesen wäre.

Um zu zeigen, was ich damit meine, kann ich auch gleich den Fehler im Assert von gfoidl aufdecken. Es ist nämlich normal, dass bei einer Addition zweier Zahlen auch ein negatives Ergebnis rauskommen kann. Man müsste den Assert also bereits erweitern:

Assert.IsTrue((val1 > 0 && val2 > 0 && result > 0) || (val1 < 0 && val2 <0 && result < 0))

Ich hab keine Ahnung, ob ich damit jetzt alle Eventualitäten drin habe. Aber genau darin liegt das problem. wenn ich mir alle Eventualitäten überlege, fange ich diese Sachen bereits bei der Realisierung ab.

Ich weiß nicht, ob ich damit einfach eine falsche Vorstellung habe, aber ihr versteht sicherlich worauf ich da hinaus will.

Gelöschter Account
vor 13 Jahren

du betrachtest es von der falschen seite. wenn du im code abfängst, das die max-values nicht addiert werden sollen, ist das korrekt und das sollst du auch machen.

dann würde der test eher so aussehen, das ich ihm die maxvalues reinschiebe und eineexception oder was auch immer erwarte.

es ist nämlich so, das wenn dein code geändert wird und z.b. jemand die prüfung der werte entfernt, oder einen codepfad einbaut der an der prüfung vorbei geht, DANN greift dein test und sagt, das sich das behavior geändert hat und das das nochmals überdacht werden soll.

im falle einer simplen addition ist das nur eine zeile code und die wahrscheinlichkeit eines veränderten codepfades oder einer änderung generell ist klein aber dennoch..... möglich.

185 Beiträge seit 2005
vor 13 Jahren

hallo,

ich finde, das beispiel demonstriert auch eine mögliche (sinnvolle?) Vorgangsweise.
Natürlich kann ich nur die Fälle in automatischen Tests abbilden, die mir "einfallen" + ev. übersehe ich dabei manche Fälle.

Hier gibt es nun die Möglichkeit:

  1. Sobald ein weiterer Fall auftritt, diesen durch einen weiteren Test abdecken.
    Ich finde, das ist "normales Vorgehen" - wenn Software entsteht, ist ja legitim, dass eine Klasse um eine Methode erweitert wird. Für diese ist dann natürlich ein Test zu schreiben, oder eben für einen Fall, den ich in meinen Tests bisher nicht berücksichtigt habe. Natürlich soll der Fehler/das Verhalten im Code behandelt werden, Test ist ja kein Ersatz für Fehlerbehandlung (wo sinnvoll) im Code.

  2. Tools für automatisches Whiteobox Testing verwenden.
    Mit diesen habe ich mich bisher auch nur theoretisch beschäftigt - was haltet ihr davon? Wenn, dann würde ich mich mal mit PEX beschäftigen: http://research.microsoft.com/en-us/projects/pex/

Die Idee dahinter ist halt, dass eine Methode automatisch mit allen möglichen Input Parametern getestet wird (einfach gesagt). D.h. Wenn die Methode int als Input parameter hat, wird ein Test erstellt, der die Methode mit 0, x, int.MaxValue aufruft. Wie gesagt - kenne das bisher nur von der Theorie und habs noch nicht in konkreten Projekten verwendet.

Dies wäre jedoch ev. eine Möglichkeit, den beschriebenen Fall abzudecken.
=> Ev. könnte man die Umfrage noch erweitern: "Ich verwende auch Tools für automatishes Whitebox testing". 😉

fg
hannes

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Mossi,

Aber genau darin liegt der Hund begraben. Man kann lediglich Sachen testen an die man selber denkt.

vollkommen klar, aber beim Testen denkt man an andere Sache als beim Programmieren. Beim Programmieren liegt der Fokus auf der Herstellung der Funktionalität. Beim Testen wird man auch - weil das ein ganz Standardvorgehen ist - an den Grenzen der Wertebereiche testen. Man nimmt beim Testen automatisch eine ganz andere Sicht sein und denkt dadurch an Sachen, an die man vorher nicht gedacht hat.

Darunter wäre aber eben nicht MinValue und/oder MaxValue gewesen,

Dann ist dein Testvorgehen noch nicht ausreichen. An dem Grenzen der Wertebereiche zu testen gehört wie gesagt standardmäßig dazu.

In diesem einfachen Beispiel hätte ich zum Beispiel einfach einen Mock geschrieben, der an die Methode ein paar für mich realistische Werte geschickt hätte.

Nur mit realistischen Werten zu testen, ist ebenfalls grundsätzlich zu kurz gesprungen.

Um zu zeigen, was ich damit meine, kann ich auch gleich den Fehler im Assert von gfoidl aufdecken.

Wunderbar! Jetzt solltest du merken, wie sinnvoll Tests sind. Der Test wäre wegen des falschen Asserts fehl geschlagen. Deshalb hätte man einen Anlass gehabt, sich näher damit auseinander zu setzen, was man eigentlich für ein Ergebnis erwartet. Auf diese Weise kommt man auf Sachen, an die man vorher nicht gedacht hat! Man hätte das Assert verbessert und wäre der Wahrheit schon wieder einen Schritt näher gekommen.

ihr versteht sicherlich worauf ich da hinaus will.

Das tue ich schon. Und ich hoffe, du verstehst, worauf ich hinaus will.

herbivore

Gelöschter Account
vor 13 Jahren

mein letzter wissensstand war, das (pex z.b.) das nur auf dem papier und bei hallo welt ausreichend gut funktioniert.

hat jemand damit erfahrungen in letzter zeit gesammelt?