Testen

[Hellhound]

Hallo zusammen,

die Entwicklung von Unit tests (z.B. mit cppunit) ist ja ein Fachgebiet, das man leider viel zu häufig vernachlässigt oder gern auch mal bewust ignoriert ... Ich seh das ja schon jeden Tag im Job, auch wenn's da "nur Java" ist und wir dort von relativ einfachen (Web-)Applikationen reden. Als QM drehe ich im 6. Jahr bereits die 3. oder 4. Runde und versuche meine Leute hier zum Testen zu bewegen. Und das im Job, wo jeder Fehler richtig Geld kostet ...

Wir sind ja "nur" Hobby Entwickler, wo dieser Mangel eigentlich kein Geld kostet, aber uns zumindest (mir jedenfalls) häufig die Zeit raubt, was meist ja eigentlich schlimmer ist. Schaut man sich mal in diesem Bereich in den verschiedenen Protalen, Literatur oder auch OpenSource Projekten um, dann wird dieses Thema auch hier meist "totgeschwiegen". Ist dem tatsächlich so?

Mich würde daher mal interessieren in wieweit Ihr selbst (z.B. mit Cppunit) testet, da dies ja allein schon aufgrund der Bibliotheksabhängigkeiten nicht ganz so einfach zu realisieren ist und vieles ja letztenldich visuell nachgetestet werden muß, grad bei 3D Applikationen. Verlasst Ihr Euch hier mehr auf die reinen Regressionstests?

Wenn Ihr testet, versucht Ihr ein möglichst breites, realistisches Spektrum abzudecken oder geht Ihr eher "Laissez-faire" mit den Tests um und baut maximal einen Happy-Path und 1,2 negativ Fälle auf?

Zudem würde mich einmal interessieren, wie Ihr Template basierte Klassen/Funktionen testet? Testet Ihr hier verschiedene Kombinationen der Typen durch um Euch abzusichern, oder schreibt Ihr wenn überhaupt maximal einen Test und nehmt dann an das die anderen Typen auch schon passen?

Gruß
Christian

[Jonathan]

Ich hab mir mal google Test angeschaut. Das sah auch ganz gut aus, aber benutzt hab ich es bisher noch nicht.
Viele Dinge schein ich damit auch schwer testen zu können. Wenn man gerade einen Shader schreibt, da hat man nicht unbedingt gute Rückgabewerte, die man testen könnte. Es wird halt am Ende was gerendert, und man muss draufgucken, wie es aussieht. Natürlich könnte man mit Aufwand den Output mit einem Referenzbild vergleichen, aber solange es nicht wenigstens einmal lief, hat man kein Referenzbild und faul wie ich bin, gehe ich meist davon aus, dass ein Feature, welches einmal funktioniert, auch später noch funktioniert, insbesondere wenn ich nichts in unmittelbarer Nähe dazu geändert habe.

Auch das ganze Aufbauen von Testumgebungen ist kompliziert. Wenn ich mein Spiel hab und da viele Komponenten zusammenspielen, kann ich einfach viel schneller gleich die ganze Anwendung ausführen und angucken. Und GUI Sachen, die zum Beispiel Qt benutzen, soll man wohl auch mit simulierten Klicks testen können, aber den Aufwand will ich wirklich nicht betreiben.
Immer wenn ein Feature fertig ist, will ich natürlich für meine Motivation das ganze live sehen, und teste es dann meiner Meinung nach ausgiebig genug, einfach auch weil es mir nach der potentiell harten Arbeit Spaß macht, mit dem Ergebnis rumzuspielen und zu sehen, wie es funktioniert.
Außerdem findet man ja quasi unmöglich alle Fehler damit. ich hatte gestern in meinem Editor das Problem, dass wenn ich die Größe der Minimap geändert habe, und dann ein Objekt hinzufügen wollte, das erste Objekt, dass ich hinzufüge an der falschen Position erscheint, alle weiteren sind danach an der korrekten Position. Bis ist mal raushatte, dass die falschen Positionen mit dem ändern der Minimapgröße zusammenhängen und wieso das verhalten Sinn macht, ist einige Zeit vergangen, aber wie hätte ich das automatisch testen können? Wie will ich zufällige GUI Interaktionen machen und danach definiert haben, welches Ergebnis rauskommen soll? Geht nicht, würd ich behaupten.

Dieser ganze Unittestkram macht für mich nur bei irgendwelchen Algorithmen Sinn, die nicht sehr komplexe Eingaben haben (sonst wird das generieren der Testfälle komplex) und ein überprüfbares und definiertes Resultat haben. Vermutlich klasse für Dinge wie Kollisionsabfrage und so (wobei ich auch hier lieber Objekte von Hand verschiebe und mir das Kollisionsergebnis anzeigen lasse, so hab ich direkt quasi unendlich viele Testfälle wo ich intuitiv sehen kann, ob das Ergebnis richtig ist, anstatt mit einer ganzen Menge an Zahlen von Hand rumrechnen zu müssen).

Vielleicht liegt es einfach an dieser interaktiven Komponente, die Spiele nunmal haben. Das Prinzip klingt viel versprechend, aber ich sehe einfach keine praktikable Möglichkeit, es einzusetzen.

[kimmi]

Automatisierte Tests sind ein Thema, dass man nicht nur mit Unittests angehen sollte. Dazumal Unittests an sich auch wirklich nur Klassen testen sollen. Ich gehe wenn meist so vor ( vorwiegend im Job, teilweise auch bei privaten Projekten ):

• Unittests zum Testen der Interfaces / konkreter Klassen, Schnittstellen per Mockups eingebunden. So weit es geht halte ich hier alle Abhängigkeiten heraus, also Einsatz von Interfaces zu Abstraktion von konkreten Implementierungen.
• Mehrere Klassen als Integrationstest testen, kann man per Cppunit implementieren. Das ist dann allerdings kein vollwertiger Unittest mehr, da ja Subsysteme getestet werden. Hier kann auch die Umgebung Einfluss nehmen. Skripte helfen ebenfalls
• Systemtest gern per Script, sofern möglich.
• Gerade Interaktionssysteme explorativ testen ( darauf rumprügeln und versuchen, das kaputt zu kriegen ). Gefundene Fehler so weit es geht in die Testsuite integrieren, um immer wieder gegen diese zu testen.

Das Ganze kostet initial einiges an Aufwand. Lebt das Projekt aber eine Weile, kann man so recht schnell sich gegen Side-Effects ausgelöst durch Änderungen absichern. Und gerade durch das bewusste Erstellen von Unittests werden die Klassen in der Regel gut testbar und haben kaum feste Kopplungen im System.

Nun wird der Eine oder Andere das für viel zu dick und durch die Interfaces etc. für nicht performant genug halten. Hier hilft Continuous Integration mit regelmäßigen Performancetests sowie die Bemühung des Profilers.

So im Groben ist es das :).

Gruß Kimmi

[Despotist]

Ich habe auch vor längerer Zeit schonmal davon gelesen aber es für mich als nicht so praktikabel erachtet. Der Aufwand ist recht hoch und gerade bei der iterativen Entwicklung ändert sich alles ständig was auch ein anpassen der Tests nötig macht. Und wenn man in "normalen" Code Bugs einbaut warum dann nicht auch in Tests?

Also sie mögen in großen Firmen und Projekten wo viele dran arbeiten und die auch ein paar Jährchen leben eine Berechtigung haben, aber für meine kleinen Projekte kommt es mir vor wie mit Kanonen auf Spatzen zu schießen. Ich bin halt nicht überzeugt dass unterm Strich wenn man Zeitaufwand gegen (nicht messbare) Zeitersparnis aufrechnet die Bilanz positiv ist (also ein Zeitgewinn).

Auch sehe ich die Gefahr dass man sich in einer falschen Sicherheit wiegt wenn die Tests alle laufen und man vielleicht die reguläre QA zurückschraubt. Es ist halt das Problem das auch die Leute die Tests machen die den Code machen und das kommt mir etwas seltsam vor. Die wissen worauf sie achten müssen und was der Code "erwartet" und bauen die Tests entsprechend. Das muss nichtmal absichtlich passieren aber viele Probleme kommen eben durch "unglückliche Umstände" zustande und die erwartet man als Programmierer selten (sonst würde der Code sie ja behandeln).

[pUnkOuter]

Wenn du vorwiegend alleine arbeitest, rechtfertigt sich der Aufwand vermutlich nicht, aber es reichen schon zwei Leute um gehörige Missverständnisse zu verursachen, die sich dann direkt auf den Code auswirken. Mit automatischen Tests kann man viele davon sofort erkennen, ohne dass man den/die Partner überhaupt erst stören müsste.

In der professionellen Welt redet man ja schon länger von Test Driven, oder jetzt sogar Behaviour Driven Design, welches vorschreibt, nur Code entwickeln zu dürfen, für welchen schon Tests geschrieben wurde. Man geht dabei so vor, dass man einen Test schreibt, und erst wenn man ein Compile-Problem hat, weil funktionaler Code fehlt, man den dann entwickeln darf. Sobald der Test wieder läuft muss man auch schon wieder mit funktionalem Code aufhören und den nächsten Test schreiben.

Behaviour Driven scheint mir fast dasselbe zu sein, ausser dass man den Begriff "Test" vermeidet, weil viele Entwickler allergisch auf diesen reagieren.

[Sternmull]

Für Hobbyprojekten hab ich glaube ich noch nie ernsthafte Tests erstellt. Dort ist der ganze Code meistens so dynamisch und vergänglich das ich selten Teile hab von denen ich glaube das sich der Zeitaufwand lohnt den ich in einen Test investieren müsste. Deshalb bleibt es dort meistens beim Coden und Ausprobieren im Endergebnis.

Auf Arbeit sieht es leider ähnlich aus. Dort gibt es aber das Problem das es megabyteweise Code gibt den keiner mehr versteht, dessen Verhalten aber unbedingt weiterhin intakt bleiben muss. Es passiert häufig das existierende Funktionalität durch die Implementierung neuer Features und natürlich auch durch Bugfixes kaputt geht. Dadurch fallen jede Menge Arbeitsstunden für Debuggen und herumorakeln an. Ich schätze das wir mehr als die Hälfte unserer Zeit mit Fehlersuche verbringen... Und dann ist da noch der Stress wenn während eines Auslieferungstests alle möglichen Fehler auftreten. Die hat vorher natürlich keiner gesehen weil alle über Monate hinweg an ihren Komponenten gebastelt haben ohne sie mal im Gesamtsystem getestet zu haben, bzw. grundsätzlich nur mit praxisfremden Setups testen konnten. Dann muss die wartende Kundschaft vertröstet werden und der Chef springt von einem anderen und setzt alle unter Druck. Nachdem die schlimmsten Sachen in größter Eile zurecht gebogen wurden, oder mit den Kunden verhandelt wurde das sie mit den Fehlern leben können, kommt die Auslieferung dann endlich doch raus. Dann gehen wieder ein paar Monate ins Land und das Spiel geht mehr oder weniger wieder von vorn los.

Bei der letzten Auslieferung gab es aber so viel Aufregung das man eiligst ein Sondermeeting einberufen hat um der Sache auf den Grund zu gehen und einen Weg zu finden mit dem man solche Probleme in Zukunft vermeiden kann. Seit ein paar Wochen steht nun bei mir die Einrichtung eines Build- und Testsystems auf dem Plan. In ein paar Wochen komm ich vielleicht wirklich mal dazu :)

Nun aber zurück zum Thema: Von reinen Unit-Tests erwarte ich mir nicht besonders viel. Vor allem wenn es um alten undokumentierten komplexen komplexen Code geht von dem man garnicht weiß welches Verhalten man von ihm erwarten soll. Deshalb strebe ich eher in Richtung Regression-Tests. Mit denen lässt sich das existierende Verhalten dokumentieren. Sobald sich eine Testausgabe verändert, muss man nachdenken ob das jetzt was schlimmes ist, oder ob es das erwartete neue Verhalten ist. Natürlich werden nebenbei noch alle Bedingungen abgetestet von denen man weiß das sie zutreffen müssen, aber dass deckt halt nur einen Teil des erwarteten Verhaltens ab. Zur Umsetzung solcher Tests hab ich vor vielen Monaten ein bisschen Code geschrieben mit dem sich mit minimalem Testfunktionen mit minimalem Aufwand schreiben lassen. Die Funktionen werden primär zwei Makros verwendet. Eins protokolliert nur mit welchem Argument es aufgerufen wurde, und was der Wert dieses Arguments war (etwa so: LOG(x +y) protokolliert "x + y = 123"). Ein anderes macht fast das gleiche, vermerkt aber einen Fehler wenn das Argument "false" ist (etwa so: TEST_ASSERT(x + y > 0) Protokolliert auch das Argument, sorgt aber dafür das der Test fehlschlägt wenn die Bedingung nicht zutrifft). Die Ausgaben landen in einem Logfile das unter Versionkontrolle gestellt wird. Wenn der Test erfolgreich verlief, wird das Logfile als erwartete Ausgabe des Tests gespeichert. Alle weiteren Testläufe schlagen Alarm wenn sie von der erwarteten Ausgabe abweichen (im Debug-Modus springt sofort der Debugger und man kann die Situation analysieren die zur unerwarteten Ausgabe geführt hat).
Bis zu diesem Zeitpunkt gab es einige Assertion-basierende Tests die von Entwicklern geschrieben wurden um neuen Code zu testen. Die lagen aber alle brach und waren in der Form auch eigentlich unbrauchbar (kryptische Ausgaben die einem nicht sagen ob der Test nun erfolgreich war oder nicht, Assertions nur im Debug-Build, ...). Diese Tests hab ich mit den oben beschriebenen Tools mit minimalem Aufwand zu brauchbaren Regression-Tests aufpolieren können.
Mit dem Ansatz bin ich erst mal sehr zufrieden. Allerdings ist die Sache noch lange nicht abgschlossen: Die Tests laufen noch nicht automatisch, sondern werden nur sehr selten manuell ausgeführt. Es fehlt auch noch eine brauchbare Statistik der Testergebnisse. Außerdem würde ich die Testfunktionen lieber über eine Skriptsprache als per Kommandozeile starten können um den Testablauf schnell und flexibel anpassen zu können (Testfunktionen in Schleifen aufrufen um auf Memory-Leaks zu testen, Reihenfolge verändern um auf Seiteneffekte zu testen, diverse Konfigurationen durchprobieren lassen, ...).
Naja, letztenendes hab ich das Rad also neu Erfunden :) Das lag einerseits an den schlechten Erfahrungen die ein Kollege bereits mit Unittest-Frameworks gemacht hat, und andererseits an meinem Unvermögen ein Framework zu finden das mich überzeugt. Wenn hier jemand ein Test-Framework kennt mit dem sich die beschriebenen Probleme mindestens genau so gut lösen lassen, dann wäre ich wirklich dankbar. Denn eigentlich will ich das garnicht alles selber schreiben. Aber so ist momentan der Stand.

Das zweite große Problem beim Testen sind die vielen unterschiedlichen Setups mit denen wir uns herumschlagen müssen: Zusammenspiel verschiedener Komponenten die als separate Pakete ausgeliefert und installiert werden, verschiedene Peripherie-Geräte die wir auch noch mit ausliefern, Windows XP vs. Vista und neuer, 32bit vs. 64bit, installation einer neuen Version über eine alte Version (und umgedreht)... Da kommen so viele Kombinationen zusammen das man sie unmöglich alle Testen kann. Wir haben zwar Testsysteme und VMs auf denen verschiedene Setups bereitstehen, aber irgendwer muss den ganzen Mist ja auch Testen. Und sobald man eine Komponente ändert, müsste man eigentlich alle Tests unter allen Setups noch mal machen, denn es könnte ja doch wieder irgendwo was kaputt gegangen sein. Es ist halt keine Zeit um immer alles zu testen (es lässt sich auch nur ein kleiner Teil automatisiert testen). Und wenn man nur kurz vor einer Auslieferung testet, dann hat man das Problem was ich weiter oben erwähnt hab: Man merkt erst viel zu spät was alles noch getan werden muss.
Zur Bekämpfung dieses Problem soll nun erst mal eine automatisch gebaute Installation des Gesamtpakets her. Momentan muss man sich noch per Remotedesktop auf verschiedenen VMs einlogen, auf der einen wir kompiliert, auf einer anderen wird die Installation erstellt, und der ganze Kram der noch dazu gehört wird von sonstwo her kopiert. Dann hat man wenigstens die Chance das Komplettpaket in seinem aktuellen Gesamtzustand zu testen. Da wir inhouse auch die ganze Zeit mit unserer eigenen Software arbeiten, können wir an unkritischen Arbeitsplätzen eine aktuelle Entwicklungsversion installieren und in der Praxis testen. Un wir Software-Entwickeler können dann auch mit Endkunden-ähnlicheren Setups testen.

So. Das war viel Text. Das Thema ist bei mir halt auf gewisse Resonanz gestoßen :)

[kimmi]

Das kenne ich. Gerade bei alten Projekten ohne automatische Tests ist das richtig herausfordernd und vor allem eins: teuer. Mittlerweile hat sich bei mir eine Erkenntnis festgesetzt: jeder Code kann irgendwann einmal produktiver Code werden, den ich oder jemand anders warten muss. Deswegen baue ich zumindest für den gängigen Anwendungsfall mittlerweile immer einen automatisierten Test, auch wenn das nur eine Kleinigkeit war.
Eine Anekdote dazu: irgendwann einmal fragte mich jemand mal: "Ich brauche mal eben ein Skript, um auf einer Persistenz ein paar Werte anzulegen." Ich baute das und gab es ihm. Eine Woche später kam der nächste und wollte wissen, wie das geht. Danach fragten die Tester, irgendwann wurde es eingecheckt, dokumentiert und wird nun als Hilfsmittel für die Produktion eingesetzt. Das Skript entstand in 5 Minuten, hatte 20 Zeilen und macht mir nun 2 Jahre später noch immer Freude ( Setups, Environments etc. ). Es ist nun auch Part einiger manueller Tests, das Ende bleibt offen...

Ohne Worte, oder?

Gruß Kimmi

[Hellhound]

Hmm was Ihr schreibt ist interessant, zumal ich hier auch immer wieder die gleichen Argumente gegen und für das Testen lese, die man mir hier tagtäglich um die Ohren haut ;) Ich muß euch zustimmen, reine Unit tests sind unzureichend und sollten auch wie Kimmi es bereits gesagt hat, nie für Regressionstests missbraucht werden, auch wenn man häufig dazu neigt. Selbst hier im Job höre ich täglich von der PL wir sollten doch mal ordendliche Unit tests über die Module hinaus aufbauen um zu testen ...

Meine bisherige Erfahrung hat mir gezeigt, dass Unit tests insofern sinnvoll sind, wenn man gegen Schnittstellen arbeitet und Elementarklassen absichert. Sobald man mit Fremdbibliotheken arbeitet, wird's hier schon schwieriger, aufgrund des Aufwands beim Stubben und Mocken, zumal ich hier die Erfahrung mache, dass das Gros der Programmierer zwar weiß es muß getestet werden, aber fast keiner jemals Unit Tests schreibt, obwohl jeder zumindest schon mal nen Buch dazu in der Hand hatte :? Naja und kommt der Faktor Zeit und der Projektdruck dazu, bricht selbst der härteste Projektleiter ein und lässt als erstes die Tests unter den Tisch fallen, auch wenn er später höheren Aufwand hat das ganze zu beheben.

Gut bei mir im Job Umfeld ist das hier sowieso nen ganz spezielles Thema. Zwar arbeiten wir für einen Konzern, aber die Abteilungen gegeneinander und jeder Projektleiter bekommt mehr Tantiemen für's sparen. Daher interessiert viele garnicht erst die langlebige Funktionalität, sondern nur die Kurzfristige und das Bugfixing wird eh später vom Support gemacht, somit habe ich keine Probleme mehr damit sobald das Teil Produktiv gesetzt wird :( Modularisierung, Kostenersparnis durch Wiederverwendung, Absicherung durch Tests sind aus Ihrer Sicht unnötige Kostentreiber, da wird lieber jedes 2. Jahr ne Applikation neu geschrieben, mit den Gleichen Fehlern und Problemen wie die Alten, aber der PL ist ja dann meist schon auf seinem neuen Posten ... Als QS bekomme ich jedes mal Ausschlag bei diesen Aussagen, da ich ja gezwungen bin langfristig die Qualität zu optimieren ...

Auch Eure Probleme mit dem Legacy Code sind mir ein bekanntest Thema. Im Java Umfeld gibt es ja einige Test-Suiten (z.B. Agitar one) die einem sogar automatisch den Code prüfen, boundaries aufzeigen und basierend auf heuristischen Werten und Erfahrungswerten automatisch Unit-Tests generieren und die Klassen "bombadieren". Tests bei uns haben gezeigt, dass sie sogar sehr gut funktionieren und echt helfen könnten, aber selbst hier kam man nach über 2 Jahren nicht zu Ergebnissen. Man diskutiert lieber ewig um lächderliche 20.000€ Jahreslizenzkosten rum, wärend man jährlich diese Summe und mehr durch das Bugfixing verbrennt ....

Und zur Anekdote kann ich nur sagen, tot gesagte leben länger :lol: Haben wir hier auch, es wurde nur mal on the scratch ein FTP Uploader geschrieben, der etwa 14 Tage im Einsatz sein sollte .... Naja, nach 3 Jahren läuft dieses Teil immer noch und macht eigentlich mehr Schmerzen als dass es hilft, aber tot zu bekommen ist der Bursche immer noch nicht und wird er wohl auch ne weile nicht werden...

Naja und test driven programming halte ich selbst für nicht durchführbar. Der theoretische Ansatz hier hinter ist gut, aber ich denke nicht das es praktikabel ist, zumal dieser Ansatz voraussetzt das der Programmierer im Vorfeld weiß was er tut. Nur leider sieht meistens hinterher alles anders aus als gedacht und man würde in dem Fall kaum vorwärts kommen, weil man ständig seine Tests während der Implementation nachziehen muß... Zumal wir uns ja ständig in einem Bereich bewegen, wo wir bestimmte Funktionalitäten erstmalig implentieren ... Da implementiere ich den Test doch lieber hinterher wenn die Funktionalität einigermaßen stabil ist ... meistens ...

Aber interessant zu hören ist das schon, dass selbst wir Hobby Programmierer, die zum Teil ja doch sehr langlebige Projekte haben eher oberflächliche Regressionstests durchführen und das bei teilweise sehr komplexen mathematischen Operationen, die an sich ja zumindest leicht durch Unit tests abgesichert werden könnten...

[kimmi]

*Angeb* In der ZFXCE und ZFXCE2 haben wir Unittests ;)... Ich bin halt faul und Unittests sparen mir Arbeit...

Gruß Kimmi

[Hellhound]

Angeb* In der ZFXCE und ZFXCE2 haben wir Unittests

Ja schon gesehen, die ZFXE2 macht ja auch schon einen recht guten Eindruck. Aber sind die Tests hier nicht z.T. auch trügerrisch?
Grad wenn ich mir z.B. den Test für's Template Array anschaue, da wird ja "nur" der float Fall getestet. Aber immerhin wird
getestet :D

Ich bin halt faul und Unittests sparen mir Arbeit...

Das mit der Faulheit liegt ja in der Natur der Sache sonst würden wir ja nicht versuchen den Rechnern unsere Arbeit
aufzudrücken :lol: Aber sehe ich genauso, Unittest können arbeit sparen ...

[kimmi]

Stimmt, zur Teit ist das noch eher wenig. Aber mnir ging es da vorwiegend darum, erst einmal einen Anfang zu machen.

Gruß Kimmi

[Jaw]

Tja auch in der Hobby Entwicklung denke ich, sollte man, und ich, idealerweise auch Testen. Jetzt nicht explizit nur Unit Test, sondern generell soweit sinnvoll automatisches Testen. Kann man ja dann auch individuell angemessen machen. Aber ich halte Zeit im Hobby Bereich für eine sehr rare Ressource, und das zweite, was mitspielt, ist Motivation. Und Fehler jagen würde ich sagen, hemmt oft eher, man kommt ja auch nicht weiter dabei, schöner ist es, wenn man neue Teile entwickelt.

Die Frage mit der Zeit ist jetzt also, ab wann lohnt sich die extra Zeit für Tests. Das Problem ist dann wohl, dass sich sowas besonders langfristig auszahlt, wenn das Projekt dann wächst, mehrere Teilnehmer hat und man selbst die eigenen Codes nicht mehr kennt, wo man 1 Jahr nicht mehr dran war. Nur in dem Moment, wo man den Test eigentlich machen sollte, je nach Philosophie vor, oder spätestens direkt nach dem jeweiligen Modul, Funktion oder was immer man da testet, da ist es einfach lästig und man wird gebremst, weil man produktive Zeit für Qualitätssicherung braucht. Nur sollte man sich wohl da dazu durch ringen, man wird sich später freuen.

Ich habe bisher leider nur ein Mal konsequent sauber mit automatischen Tests gearbeitet, geschrieben nachdem die jeweiligen Klasse fertig war, und es war einfach geil. Als ich dann Änderungen hatte, flupp, 5 Sekunden, laufen 200 Tests durch und sagen, is alles noch ok. Das war ein enormes Maß an Sicherheit, wenn man an Stellen fummelt, und die Auswirkungen kaum abschätzen kann.

-JAW

[Tejio]

Um den Thread ein wenig aus der Mottenkiste rauszuholen, wollte ich mal fragen, ob jemand Erfahrungen mit Fit gesammelt hat. Es scheint ja ein interessantes Tool zu sein...

[Krishty]

SCNR :)

Fit klingt so nach Blackbox Testing … da graut es mir.

[eXile]

Zum Thread:

Der Vorteil liegt darin, dass der Testautor keine Programmierkenntnisse benötigt.

Und das halte ich für ein Gerücht. Beim Testen muss man immer Grenzfälle mit testen, und solche Grenzfälle können kaum von externen Personen aufgespürt werden, weil diese nun einmal nicht mit dem Code vertraut sind. Das kann für kleinere buchhalterische Programme vielleicht noch nicht so wichtig sein, aber spätestens wenn numerische Optimierungsalgorithmen genutzt werden, ist der Ofen aus.

Zu Krishty:
Dann bitte auch Quelle mit angeben ;). Source (via).

[Krishty]

Und das halte ich für ein Gerücht. Beim Testen muss man immer Grenzfälle mit testen, und solche Grenzfälle können kaum von externen Personen aufgespürt werden, weil diese nun einmal nicht mit dem Code vertraut sind. Das kann für kleinere buchhalterische Programme vielleicht noch nicht so wichtig sein, aber spätestens wenn numerische Optimierungsalgorithmen genutzt werden, ist der Ofen aus.

Ein wie gespuckt passendes Beispiel ist dieser Bug in Windows XPs File Comparison Tool, das versagt, wenn sich die jeweils 128ten Bytes zweier Dateien unterscheiden m[ Ich wette, die haben einfach automatisiert Dateien mit rand() gefüllt, ein assert(!equal); dahintergesetzt und es, nachdem eine Woche keine Assertion flog, freigegeben.

Dann bitte auch Quelle mit angeben ;). Source (via).

Stimmt; eigentlich zu geil, um es der Welt vorzuenthalten. War aber via was anderem.

[Lynxeye]

Ohne mir das Tool jetzt genauer angesehen zu haben, aber wir haben hier in der Firma (kommerzielle) Tools im Einsatz, die genau das finden dieser Grenzfälle extrem vereinfachen. Und dafür braucht man wirklich kein Programmiergott sein, die Teile kann eigtl. jedes Kind bedienen und damit in 95% aller Fälle bessere Unittests schreiben, als der Autor der Funktionen/Klassen.

[eXile]

Ohne mir das Tool jetzt genauer angesehen zu haben, aber wir haben hier in der Firma (kommerzielle) Tools im Einsatz, die genau das finden dieser Grenzfälle extrem vereinfachen.

Gut, das ist natürlich etwas anderes. Beim oben beschriebenen Tool war in keiner Weise die Rede davon, dass da zusätzliche Intelligenz in Form von weiteren Tools zum Auffinden von Grenzfällen reingesteckt wird. Dürfte ich fragen, um welche „kommerziellen Tools“ es sich handelt? Inwiefern ist damit ein Externer, der das Tool benutzt, besser als einer der Programmierer des Codeabschnitts, der das Tool benutzt? Was wäre im Falle von Krishtys Link los?

Ein leidiger Anwendungsfall von meiner Seite aus lag darin, in einem CG-Solver in manchen Fällen numerische Ungenauigkeiten zu debuggen. Im Endeffekt konnte man diese Ungenauigkeiten durch Ausnutzung des Distributivgesetzes und ein paar weiteren „if x near epsilon“ beseitigen. Falls ihr euch mal gefragt habt, warum eigentlich alle Implementierungen von numerischen Algorithmen aussehen wie ein langer Grütze-Wurm: Genau deswegen. Man erstellt tausende Variablen, um ja nicht mehrere Operationen in einer Zeile zu haben, welche man dann zum Debuggen wieder auseinanderfriemeln muss, um die böse Operation zu finden.

Ich möchte den Sinn und Zweck von Testern und QA in keiner Weise abstreiten. Es ist gut, dass auch mal einer „von draußen“ auf die jeweilige Funktionalität schaut, und ganz davon abgesehen sehen mehr Leute nun einmal einfach mehr Fehler. Außerdem können Tester natürlich das Programmierteam entlasten. Das entbindet aber die Programmierer nicht von der Pflicht, sorgfältig zu arbeiten. ;)

Wie es der Zufall will, ist gerade über die Feeds noch ein Blogpost reingerauscht, welcher spezifisch auf das (regression) testing bei Unity eingeht: http://aras-p.info/blog/2011/06/17/test ... ars-later/

[Lynxeye]

Gut, das ist natürlich etwas anderes. Beim oben beschriebenen Tool war in keiner Weise die Rede davon, dass da zusätzliche Intelligenz in Form von weiteren Tools zum Auffinden von Grenzfällen reingesteckt wird. Dürfte ich fragen, um welche „kommerziellen Tools“ es sich handelt? Inwiefern ist damit ein Externer, der das Tool benutzt, besser als einer der Programmierer des Codeabschnitts, der das Tool benutzt? Was wäre im Falle von Krishtys Link los?

Eine Kombination von Tools aus dem Hause Parasoft. Externe Tester haben nicht den Tunnelblick, welchen die Programmierer nach dem fertigstellen der Funktion/Klasse an den Tag legen. Im Kopf der Programmierer festigt sich meist ein Satz an Annahmen, was alles nicht passieren kann, obwohl diese Annahmen meist nicht einmal hinterfragt wurden.

Im Falle von Krishtys Link gehe ich davon aus, dass es ein einfacher off-by-one Fehler ist. So etwas lässt sich leicht durch analysieren der Feldgrößen und dem darauf angewendeten Code finden, auch automatisch und damit gezielt Unittests schreiben, welche genau die Grenzen von bestimmten Datentypen oder Schleifen abtesten.

Mit Hilfe dieser Tools braucht der Tester auch nur ein grundlegendes Verständnis von der Programmierung, die Tests an sich werden "zusammengeklickt". Und meiner Erfahrung nach schreiben Programmierer nur stümperhafte Tests, behaupten dann aber stur "Testen kann ja jeder".

Ich selbst mache manuelle Code-Reviews und was da an WTFs schon durch selbst geschriebene Unittests gemogelt hat ist einfach nicht mehr schön.

[Tejio]

...
Mit Hilfe dieser Tools braucht der Tester auch nur ein grundlegendes Verständnis von der Programmierung, die Tests an sich werden "zusammengeklickt". Und meiner Erfahrung nach schreiben Programmierer nur stümperhafte Tests, behaupten dann aber stur "Testen kann ja jeder".
...

Bedarf es dabei eines externen Testers oder braucht man als Programmierer eine spezielle Schulung, um solche Tests in einem ordentlichen Zustand zu verfassen? Mir fällt die Erstellung von Testfällen etwas schwer...

[Alexander Kornrumpf]

Mit industriellen Tests hab ich keine Erfahrung, aber ich habs schon sehr oft erlebt dass ich irgendwas "vorgezeigt" habe und der Benutzer hat als erstes irgendetwas versucht womit ich NIE gerechnet hätte was dann mindestens ein missing Feature (in letzter Zeit) oder sogar einen schlimmer Bug (früher öfter, aber natürlich nie ganz verschwunden) zum Vorschein brachte. Insofern scheint mir die Idee das Programmierer und Tester verschiedene Personen sein sollten nicht unbedingt abwegig.