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:

Empirische Studie

beantworten | zitieren | melden

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

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 184
Herkunft: Hamburg

beantworten | zitieren | melden

@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.
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
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
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,

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

Avatar #avatar-3115.jpg


Dabei seit:
Beiträge: 184
Herkunft: Hamburg

beantworten | zitieren | melden

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.
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 Ralf,
Zitat
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!"
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!

@ralfw:
Zitat
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.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von tom-essen am .
Nobody is perfect. I'm sad, i'm not nobody
private Nachricht | Beiträge des Benutzers
dr4g0n76
myCSharp.de - Experte

Avatar #avatar-1768.jpg


Dabei seit:
Beiträge: 3047
Herkunft: Deutschland

beantworten | zitieren | melden

@Ralfw:
Zitat
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.
Zitat
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.
Zitat
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.
Zitat
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.
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

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....
dr4g0n76
myCSharp.de - Experte

Avatar #avatar-1768.jpg


Dabei seit:
Beiträge: 3047
Herkunft: Deutschland

beantworten | zitieren | melden

Interessant für tests:

Microsoft VS 2008 - Spec Explorer (natürlich auch für VS2010)
Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

beantworten | zitieren | melden

Zitat von ralfw
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.
Zitat von ralfw
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.
Zitat von ralfw
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.
Zitat von ralfw
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?
Zitat von ralfw
Wenn du zufrieden bist, dann lass es.
Ich bin eigentlich schon zufrieden. Aber vielleicht bin ich noch viel zufriedener, wenn sich meine Bugs halbieren.
Zitat von herbivore
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.
private Nachricht | Beiträge des Benutzers
winSharp93
myCSharp.de - Experte

Avatar #avatar-2918.png


Dabei seit:
Beiträge: 6155
Herkunft: Stuttgart

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von winSharp93 am .
private Nachricht | Beiträge des Benutzers
Mossi
myCSharp.de - Member

Avatar #avatar-2646.jpg


Dabei seit:
Beiträge: 200
Herkunft: Regensburg

beantworten | zitieren | melden

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.
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
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!"
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 Mossi,
Zitat
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
private Nachricht | Beiträge des Benutzers
Mossi
myCSharp.de - Member

Avatar #avatar-2646.jpg


Dabei seit:
Beiträge: 200
Herkunft: Regensburg

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

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.
HannesB
myCSharp.de - Member

Avatar #avatar-2666.gif


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

beantworten | zitieren | melden

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
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von HannesB am .
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 Mossi,
Zitat
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.
Zitat
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.
Zitat
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.
Zitat
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.
Zitat
ihr versteht sicherlich worauf ich da hinaus will.
Das tue ich schon. Und ich hoffe, du verstehst, worauf ich hinaus will.

herbivore
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

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?
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal am .
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 7547
Herkunft: Waidring

beantworten | zitieren | melden

Hallo,
Zitat
den Fehler im Assert von gfoidl
Mein Assert ist schon richtig denn das wird nur für einen Test für positive Eingaben verwendet. Und da sollte bei der Addition eben ein positives Ergebnis herauskommen.

ad PEX: Siehe Unit-Tests mit PEX


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
userid12529
myCSharp.de - Member



Dabei seit:
Beiträge: 210

beantworten | zitieren | melden

Zitat von Mossi
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.
Niemand denkt immer an alle Eventualitäten. Und gerade deshalb sollte man doch auch Tests schreiben. Bei der Erstimplementation einer Funktionseinheit wirst du nur so viele Fälle abdecken, die dir einfallen, geht ja nicht anders. Wenn dann aber die Software irgendwann in Betrieb ist und bei irgendeinem Anwender tritt aufgrund ungewöhnlicher Eingaben oder Eingaben, an die du nicht gedacht hast, ein Fehler auf, dann kannst du speziell diesen Fall mit einem Test abdecken und stellst sicher, dass der Fehler ein für alle mal behoben ist. Nicht, dass bei einer weiteren Änderung am Code der Fehler noch mal versehentlich eingebaut wird.
private Nachricht | Beiträge des Benutzers
BhaaL
myCSharp.de - Member

Avatar #erP6yAFiewXrJTqrvg6R.jpg


Dabei seit:
Beiträge: 655

beantworten | zitieren | melden

Problem bei Pex ist oft, dass es bei etwas "komplexeren" Sachen oft schon ansteht und nicht mehr weiterkann (was mir oft passiert ist, bis ichs irgendwann mal sein gelassen hab: Parameter-Objekte, die mehrere andere Parameter zusammenfassen und im Vorfeld schon validieren). Und dort per Code und den von Pex benötigten Object Factories nachhelfen funktioniert(e) damals auch nicht ganz reibungslos.
Umgekehrt konnte ich aber mit CrashTest.net teilweise bessere Ergebnisse erzielen als mit Pex (hat manchmal die Parameter-Objekte richtig gemacht), war dafür ab und zu nicht ganz so stabil (bleibt hängen, reagiert nicht mehr oder stürzt auch mal mit einer unhandled Exception ab).


Um zu den Tests als Dokumentation, TDD und Co zurück zu kommen:
Was ich schon mehrmals gemacht habe, war die Anforderungsdokumente von Kunden und/oder Vorgesetzten als Test zu formulieren - damit ist mal sichergestellt, dass das funktioniert, was gefordert ist. Natürlich TDD-Style, erst den Test, dann implementieren. Im Anschluss kurz die Code-Coverage anschaun, ob irgendwas nicht durch den Test erwischt wurde; dafür schreib ich dann ggf. auch was (Alles natürlich unter der Vorraussetzung, dass die Anforderungsdokument auch einigermaßen das enthalten, was man braucht - und nicht was man denkt dass man braucht. Aber das Problem gibts überall und muss man irgendwo selber abschätzen können).

Für Fälle, die ich nicht kenne, schreibe ich logischerweise auch keinen Test. Vor allem: sollte so ein Spezialfall fehlschlagen, muss ich mit ziemlicher Sicherheit sowiso den Code anpassen und ggf. auch weitere Tests schreiben. Da halte ich es wie mit den Exceptions, don't catch what you don't expect.


Einen Punkt habe ich oben bewusst nicht erwähnt, den ich aber teilweise bei meinen Kollegen sehe oder zumindest schon mehrmals als Diskussionspunkt hatte:
Testet ihr (erfolgreiche) Fälle von Konstruktoren und Properties? Beispiel: Ctor setzt das Property "Name" auf den übergebenen Wert, Test mit

Assert.Equals(expected, new MyObject(expected).Name);
Oder es gibt eine automatische Property Name; testet ihr dort ob das Framework das richtige tut; zur Sicherstellung dass es sich auch in Zukunft so verhält (und nicht dass mal eine Validierung im set reinkommt, die alles kaputt macht):

class UnderTest { public string Name { get; set; } }
[...]
Assert.DoesNotThrow(() => underTestInstance.Name = expected);
Assert.AreEqual(expected, underTestInstance.Name);
private Nachricht | Beiträge des Benutzers
Sageniuz
myCSharp.de - Member



Dabei seit:
Beiträge: 1

beantworten | zitieren | melden

@Rainbird

Ich habe diesen Thread noch nicht bis zum Ende gelesen aber bis jetzt wurde dieses Buch noch nicht erwähnt: "Springer 2010 Test-Driven Development An Empirical Evaluation of Agile Practice" Amazon

Ich habe das Buch noch nicht gelesen da ich auch so von TDD und Unit-Tests überzeugt bin, allerdings beantwortet es vielleicht Deine Fragen.

LG.
private Nachricht | Beiträge des Benutzers
martinO
myCSharp.de - Member



Dabei seit:
Beiträge: 166

beantworten | zitieren | melden

Ich glaube, das folgende Argument (pro) TDD ist bislang noch nicht erwähnt worden:
- Man kann sicherstellen, dass der Code so verwendet wird, wie es zur Designzeit gewünscht ist.

... dann schreibe ich einen Test dafür und wenn jemand meinen Code ändert, failed ein Test. Dann muss er zumindest diesen auch noch anpassen und überlegt sich vielleicht, ob seine Änderung überhaupt sinnvoll ist, wenn dafür speziell ein Test existiert, der dies verhindert...

(ich hoffe, ich hab mich genug deutlich ausgedrückt ;) )
private Nachricht | Beiträge des Benutzers
wickedcsharper
myCSharp.de - Member

Avatar #avatar-3141.jpg


Dabei seit:
Beiträge: 167
Herkunft: Köln

beantworten | zitieren | melden

Da ich mich mit genau dem Thema gerade beschäftige
ist die Sache für mich sehr interessant, denn:

a) sind automatisierte Tests eine tolle Sache - vor allem wenn einer an meinem Code fummelt und dann Funktionen nicht mehr funktionieren.

b) es für Kunden natürlich nichts blöderes und ärgerlicheres gibt , als einmal funktionierende Sachen wieder zu bemängeln

c) die Wartung im Nachhinein wesentlich vereinfacht werden kann

aber:

Projekte sind oft zeitkritisch. Und wenn der Chef oder der Kunde morgen neue Funktionen haben will und ich ihm mitteile für die eigentliche Aufgabe gerade bis morgen fertig werde aber zusätzlich noch Testfunktionen implementieren muss,
dann klatscht der Ledernacken.

Für die Chefetage und somit meist Nichtprogrammierer ist das ganze oft ein unverständlicher zeit und kostenintensiver Faktor, der auf Inakzeptanz stößt
(meist zumindest). Berühmte Worte meines Ex-Chefs waren immer: Das haben wir doch schon alles mal programmiert - wieso dauert das solange....

...und da liegt die Sache im Argen. Wer gibt einem die Zeit dafür, für jede Klasse, Funktion und eventuell Variable eine zusätzliche Testfunktion zu schreiben.

In kleinen Projekten würde ich sogar darauf verzichten. Ich denke je größer und kostenintensiver das Projekt ist, desto mehr lohnt sich auch ein abgestellter Testentwickler oder Qualitätsmanager. Aber aufs Jahr gesehen kostet der auch fast 100.000 Euro mit Lohnnebenkosten. Wers hat...

Den Kunden zu verärgern und Fehler immer wieder neu aufzudecken kann aber genauso teuer werden.
„Wenn man eine Katze auseinandernehmen will, um zu sehen, wie sie funktioniert, hat man als erstes eine nicht funktionierende Katze in den Händen.“
private Nachricht | Beiträge des Benutzers
delta†
myCSharp.de - Member



Dabei seit:
Beiträge: 46

beantworten | zitieren | melden

hier ist es zwar schon ein paar wochen ruhig!? ich finde es sinnvoll dass ein entwickler sich - auf dauer gesehen - testwissen aneigent um seine strukur der programmierung entsprechend weiterzuentwickeln!

meistens wird der komponententest bei den entwicklern durchgeführt, wobei es hier mehr sinn macht das buddy-testing angewendet wird - aus dem einfachen grund das der entwickler der komponente meist unter betriebsblindheit leidet oder das projekt oder die firma sehr klein ist und die ressourcen nicht für einen testabteilung reichen.

mal abgesehen davon sollte man jedoch auch wissen über die testfallbildung mitbringen wie z.b. äquivalenzklassenbildung, grenzwertanalyse, bedingungsübdeckung, etc. und sich mit gewissen metriken z.b. mccabe auseinandergesetzt haben. es gibt auch bücher mit fehlerlisten die unter umständen recht sinnvoll sein können.

oft wird testen mit dem finden von fehlern gleichgesetzt. grundsätzlich kann man mit dem testen die existent von fehlern nachweisen - jedoch nicht die abwesenheit. dies ist aber nur ein teil der absicht des testprozesses. der sinn ist auch das die sw-qualität (gebrauchsqualität sowie innere und äußere qualität) gesteigert wird und sich damit etliche kostenfaktoren senken lassen. man sollte natürlich auch beachten das es neben den dynamischen methoden wie blackbox und whitebox auch noch die statischen gibt welche oftmals ganz andere perspektiven und damit andere testfälle zum vorschein bringen.

delta†
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von delta† am .
private Nachricht | Beiträge des Benutzers
user8744
myCSharp.de - Member



Dabei seit:
Beiträge: 1201

beantworten | zitieren | melden

Ohne irgendwelche Antworten hier gelesen zu haben.

Server-Entwickler: Meine Unit Test funktionieren!

Ich: Ich rufs auf und bekomm ne Exception.

Meine Meinung von Unit Tests ist eine eher schlechte.
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 Sebastian.Lange,

aufgrund eines Einzelfalls sollte man kein grundlegendes Urteil fällen.

Davon abgesehen ist aufgrund deiner sehr knappen Beschreibung überhaupt nicht klar ist, ob es überhaupt einen Widerspruch zwischen den beiden Aussagen gibt. int.Parse ist auch ausführlich getestet. Und trotzdem kommt bei int.Parse ("hallo") eine Exception. Das ist ja vollkommen korrekt.

Außerdem musst du zwischen Korrektheit und Robustheit unterscheiden. Korrektheit bedeutet nur, dass eine Methode, die korrekt ist, das tut, was die Spezifikation verlangt. Legt die Spezifikation die Aufgabe der Methode nur für einen Teilmenge der möglichen Eingaben fest, dann ist keine Aussage darüber getroffen, was die Methode tun soll, wenn ein Eingabewert außerhalb des durch die Spezifikation definierten Wertebereichs liegt. Wenn die Methode dann Unsinn macht, ist sie nicht robust, aber sie kann trotzdem korrekt sein, weil sich Korrektheit nur auf die gültigen Eingaben bezieht.

Aber selbst wenn die Methode, die du aufgerufen hast, nicht korrekt war und die Exception fälschlich geworfen hat, sag das doch immer noch nichts darüber aus, ob es sinnvoll ist, Unit-Tests einzusetzen. Tests können normalerweise nicht die Abwesenheit von Fehlern beweisen. Das Unit-Tests erstellt wurden, heißt also nicht, dass die Unit vollkommen fehlerfrei ist. Die Frage ist, ob die Unit weniger Fehler enthält, wenn Unit-Tests erstellt wurden. Und das kann man mit Fug und Recht als empirisch bewiesen ansehen.

Vermutlich macht deinen Beispiel einfach keine Aussage über den Sinn von Unit-Tests, sondern nur über die (mangelnde) Qualifikation dieses einen Entwicklers.

herbivore
private Nachricht | Beiträge des Benutzers
Golo Roden
myCSharp.de - Member

Avatar #avatar-2167.png


Dabei seit:
Beiträge: 4649
Herkunft: Riegel am Kaiserstuhl

beantworten | zitieren | melden

Hallo,

um mich auch mal noch einzuklinken: Ich war ja bis vor rund 9 Monaten auch einer derjenigen, die gesagt haben: Unittests - ja, ganz nett, aber viel zu umständlich, viel zu aufwändig, erfordert viel zu oft Umstrukturieren von Code, ... wer meine Argumentation von damals noch mal haben will, kann dies gerne in meinem Blogeintrag "Wie viel Sinn machen Unittests?" (http://www.des-eisbaeren-blog.de/post.aspx?id=c9a5d57d-7337-49f8-b950-c082d49b2fdb) machen.

Heute, 9 Monate später, sehe ich das Ganze komplett anders.

Auf meinen Blogeintrag kamen etliche Kommentare, die mich erschreckt haben - und glücklicherweise dazu veranlasst, es noch einmal zu versuchen. Ich habe mich danach ausführlich mit Unittests und TDD beschäftigt, viel gelesen - aber, was noch wichtiger ist: Viel herumprobiert und mit anderen diskutiert.

Das Ergebnis: Ich habe festgestellt, dass ich den wahren Nutzen von Unittests früher gar nicht erkannt habe. Früher dachte ich, es geht darum, Fehler zu finden.

Heute weiß ich: Es geht darum, ein Sicherheitsnetz zu haben, das es mir ermöglicht, bedenkenlos Änderungen am bestehenden Code durchzuführen - mit der Garantie, dass ich nichts aus Versehen kaputt mache oder die bestehende Semantik ändere.

Und auch TDD weiß ich heute sehr zu schätzen: Es fördert gutes Design, man macht sich viel mehr Gedanken über Terminologie, Struktur, ... und vor allem: Man schreibt nur so viel Code wie nötig, hält alles damit kompakt, refaktorisiert regelmäßig, ...

Natürlich kostet das ganze Aufwand. Dieser Aufwand fällt aber gar nicht so sehr während der Entwicklung ins Gewicht - sondern vielmehr während des "sich Eingewöhnens". Unittests und vor allem TDD fühlen sich zu Anfang ungewohnt an - und deswegen scheut man sie (zumindest ging mir das so). Inzwischen bin ich froh, diese Veränderung durchgemacht zu haben.

Ich entwickle derzeit ein neues Projekt, Greenfield, .NET 4.0 - komplett mit TDD. Es käme mir nicht mehr in den Sinn, es anders zu machen. Die Tests haben mir schon ein paar Mal geholfen, bei Refaktorisierungen auf der sicheren Seite zu bleiben. Ohne sie hätte ich schon einige Fehler eingebaut, von denen ich nichts ahnen würde ... und die dann irgendwann irgendwo auftreten - im dümmsten Fall nach der Auslieferung beim Kunden.

Insofern: TDD? Nie mehr ohne :-)!

Viele Grüße,


Golo
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de
private Nachricht | Beiträge des Benutzers