Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Tatsächlicher Nutzen von Unit-Tests [und TDD]
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

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

beantworten | zitieren | melden

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 (?)
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
dN!3L
myCSharp.de - Experte

Avatar #avatar-2985.png


Dabei seit:
Beiträge: 3138

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Tests als Treiber für saubere Architektur

beantworten | zitieren | melden

Zitat von dN!3L
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.
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo Rainbird,
Zitat
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
private Nachricht | Beiträge des Benutzers
dN!3L
myCSharp.de - Experte

Avatar #avatar-2985.png


Dabei seit:
Beiträge: 3138

beantworten | zitieren | melden

Zitat von herbivore
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
private Nachricht | Beiträge des Benutzers
winSharp93
myCSharp.de - Experte

Avatar #avatar-2918.png


Dabei seit:
Beiträge: 6155
Herkunft: Stuttgart

beantworten | zitieren | melden

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...
private Nachricht | Beiträge des Benutzers
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 7547
Herkunft: Waidring

beantworten | zitieren | melden

Hallo,
Zitat von herbivore (leicht modifiziert)
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!"
private Nachricht | Beiträge des Benutzers
ralfw
myCSharp.de - Member

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 184
Herkunft: Hamburg

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
m.knigge
myCSharp.de - Member

Avatar #avatar-3136.png


Dabei seit:
Beiträge: 178
Herkunft: Hannover

beantworten | zitieren | melden

Zitat von Rainbird
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.
private Nachricht | Beiträge des Benutzers
mg.net
myCSharp.de - Member



Dabei seit:
Beiträge: 155

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
martinO
myCSharp.de - Member



Dabei seit:
Beiträge: 166

beantworten | zitieren | melden

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

Welche Gründe - ausser der zusätzliche Zeitaufwand - gibt es? (Zeit ist Geld, etc...)
private Nachricht | Beiträge des Benutzers
HannesB
myCSharp.de - Member

Avatar #avatar-2666.gif


Dabei seit:
Beiträge: 185
Herkunft: Österreich

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
fielding
myCSharp.de - Member



Dabei seit:
Beiträge: 62

beantworten | zitieren | melden

Zitat von ralfw
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
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von fielding am .
private Nachricht | Beiträge des Benutzers
dr4g0n76
myCSharp.de - Experte

Avatar #avatar-1768.jpg


Dabei seit:
Beiträge: 3047
Herkunft: Deutschland

beantworten | zitieren | melden

@Rainbird:

Ein Verweis hierauf sei noch erwähnt:


Meine Erfahrungen zu Unit-Tests

Auszug aus Clean Code:
Zitat
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:
Zitat
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.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von dr4g0n76 am .
Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.
private Nachricht | Beiträge des Benutzers
Stefan O.
myCSharp.de - Member



Dabei seit:
Beiträge: 72
Herkunft: Bergisch Gladbach

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Beweise

beantworten | zitieren | melden

Zitat von dr4g0n76
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.
Zitat von dr4g0n76
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.
Zitat von dr4g0n76
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?
Zitat von dr4g0n76
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.
private Nachricht | Beiträge des Benutzers
dr4g0n76
myCSharp.de - Experte

Avatar #avatar-1768.jpg


Dabei seit:
Beiträge: 3047
Herkunft: Deutschland

beantworten | zitieren | melden

Zitat:
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:
Zitat
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.
private Nachricht | Beiträge des Benutzers
dr4g0n76
myCSharp.de - Experte

Avatar #avatar-1768.jpg


Dabei seit:
Beiträge: 3047
Herkunft: Deutschland

beantworten | zitieren | melden

noch einen gefunden:

Economic Impact...
Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.
private Nachricht | Beiträge des Benutzers
ralfw
myCSharp.de - Member

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 184
Herkunft: Hamburg

beantworten | zitieren | melden

Zitat
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
Zitat
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.
Zitat
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.
Zitat
Aber ich denke, dass der Aufwand den Nutzen am Ende übersteigt.

Definiere Nutzen.
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8775
Herkunft: Berlin

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Analyse

beantworten | zitieren | melden

@dr4g0n76: Danke für die Links!

@ralfw: Ebenfalls, danke für die Links!
Zitat von ralfw
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.
Zitat von ralfw
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).
private Nachricht | Beiträge des Benutzers
HannesB
myCSharp.de - Member

Avatar #avatar-2666.gif


Dabei seit:
Beiträge: 185
Herkunft: Österreich

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
ralfw
myCSharp.de - Member

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 184
Herkunft: Hamburg

beantworten | zitieren | melden

Zitat
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 ;-)
private Nachricht | Beiträge des Benutzers
martinO
myCSharp.de - Member



Dabei seit:
Beiträge: 166

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
tom-essen
myCSharp.de - Experte

Avatar #avatar-2140.png


Dabei seit:
Beiträge: 1928
Herkunft: NRW

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
fielding
myCSharp.de - Member



Dabei seit:
Beiträge: 62

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
DaMoe80
myCSharp.de - Member



Dabei seit:
Beiträge: 508

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
dr4g0n76
myCSharp.de - Experte

Avatar #avatar-1768.jpg


Dabei seit:
Beiträge: 3047
Herkunft: Deutschland

beantworten | zitieren | melden

@Rainbird: Um nochmal auf Deine Fragen zu Beginn zurückzukommen:
Zitat
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).
Zitat
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:
Zitat
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.
private Nachricht | Beiträge des Benutzers
SeboStone
myCSharp.de - Member



Dabei seit:
Beiträge: 495

beantworten | zitieren | melden

Zitat von svenson
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.
private Nachricht | Beiträge des Benutzers