Also wenn ich das jetzt richtig verstanden hab, testet man damit tatsächlich kurze einfache Funktionen, bei denen man eizelne Werte noch auf einem anderen Weg ausrechnen kann.
Also in etwa so, wie wenn ich zB sin implementieren würde (ok, leicht sinnlos, aber einmal angenomen, das wäre noch nicht in hardware implementiert) und das zB über Taylorreihen ausrechnen würde, dann würde ich die Werte testen, die sich auch anders berechnen lassen (0°, 30°, 45°, 60°, 90°...) Soweit richtig?
Aber irgendwelche Funktionen, die sich für alle Werte nur so ausrechnen lassen, wie´s implementiert ist (bzw, wenn die Alternative extrem kompliziert oder mir nicht bekannt ist) lassen sich nicht testen? Dabei gefallt mir mein Spaghetticode doch so gut
Wobei, wenn ichs mir recht überleg, hab ich sowas ähnliches auch schon mal gemacht. Nur dass ich dazu den Debugger benutzt hab (selber nachschaun, obs genug gleich ist ), und deswegen bei codeänderung das ganze von Neu machen hätte müssen
So in der Art, ja. Man ist da extrem flexibel, was genau man testet und muss (und sollte) nicht nur Randfälle testen. Manchmal hat man vor lauter Fokus auf die Spezialfälle den Blick für das Normale verloren und da Fehler eingebaut. Letztendlich sind Unit-Tests aber tatsächlich nichts anderes wie das Nachschauen im Debugger, ob eine Variable auch wirklich den Inhalt hat, den sie haben sollte. Nur dass das ganze automatisiert abläuft und viele viele (positive) Sachen nach sich zieht.
_________________ "Für kein Tier wird so viel gearbeitet wie für die Katz'."
Ein Thema mit dem ich demnächst auseinandersetzten muss, denn bei uns in der Firma soll die Qualität der Software durch Unit-Tests erhöht werden.
Da wir aber Hauptsächlich Customizations für Kunden schreiben, die immer mit Unterschiedlichen Daten arbeiten ist das nicht so leicht da Unit-Tests vernünftig einzusetzten.
Vor allem wenn man Migrationswerkzeuge schreibt die Daten A nach B konvertieren. Um die Ergebnisse von Daten A mit Daten B zu vergleichen müssen A immer Identisch sein damit auch B rauskommt. Sobald was verändert wird an A dann stimmt das ergebnis zu B nicht mehr.
Eine gute Basis für Unit-Tests zu schaffen ist keine leichte Aufgabe. Das will gut überlegt werden. Falls ihr eure Daten in SQL-fähigen Datenbanken haltet, kann ich DBUnit empfehlen. Das geht dann zwar wieder mehr Richtung Integrationstests, aber so wie das klingt wollt ihr auch eher Integrations- als Unit-Tests. Erfordert allerdings Javakenntnisse. In der C#-Welt kenn ich nichts vergleichbares (hab mich da auch nicht umgeguckt ^^).
Falls irgendwie möglich, würde ich die Daten als Plaintext vorhalten. Das verträgt sich einfach wesentlich besser mit Versionierungssystemen.
Grüße, ~ Frase
Tante Edith meint: Im übrigen ist es meist ziemlich aufwändig, Software nachträglich mit Unit-Tests abzutesten. Wenn der Code nicht mit Testbarkeit im Hinterkopf geschrieben wurde, muss man sehr viel mocken und stubben. Das relativiert den Nutzen dann ein wenig...
_________________ "Für kein Tier wird so viel gearbeitet wie für die Katz'."
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2623 Wohnort: Berlin
Programmiersprache: Go, C/C++
Alles Funktionen bestehen aus einen oder mehreren Fällen. Bei einer Sinus Funktion z.B. gibt es Werte zwischen 0 und 2PI, 0 bis -2PI, über 2PI und unter -2PI. Nun kann man jeden Fall mit einem Test versehen. So sollte bei >+-2PI das gleiche raus kommen wie der Radiant modulo 2PI.
Je komplexer die die Funktion wird, des so mehr Fälle gibt es und des so mehr kann man testen. Da aber selbst die Unit-Test Fanatiker sagen, dass man mit den besten Unit-Test abdeckung trotzdem nicht alle Bugs verhindern kann, tut man in der Regel dich wichtigsten funktionen testen. Bei einem MMORPG z.B. müsste alles, was mit Netzwerk und Datenverwaltung zu tun hat getestet werden. Dinge wie Graphic, Gamelogik, Physik, Sound und so weiter sind hier weniger wichtig und stehen hinten an. Jedes If, else, switch, case und so weiter sorgt für ein weiteren Test und da man da schnell die Übersicht verlieren kann, gibt es code covarage tools. Dieses läuft über den Unit-Test drüber und sagt, welche branches vom code nicht durchlaufen wuden und diese müssten halt noch durch test durchlaufen werden. Unter Java gibt es tonnen weise solcher tools, bei C++ sieht das anders aus, da gibt es ne hand voll und kostenfreie gibt es noch viel weniger(funktionierende und gepflegte hab ich noch garnicht gefunden).
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7810 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Wobei das bei Komplexer SW von Alleine auch passiert. Wir müssen massiv komplexe Testdaten erzeugen um bestimmte Komponenten zu testen. Das liegt einfach daran, dass die Daten die diese Komponeten verarbeiten halt sehr komplex sind.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Auch interessant sind Regressiontests. Das bedeutet im Prinzip bei einer Änderung nochmal alles durchzuchecken, aber statt sich von außen oder von Weltwissen Kontrolldaten zu holen, testet man verschiedene Versionen. Auf diese Art und Weise kann man natürlich wahnsinnig viel testen.
Wenn man z.B. Optimierungen an einer Datenbank, Physikengine, Browserengine oder was auch immer vornimmt, kann man so testen, ob das Ergebnis noch das gleiche ist.
Im einfachsten Falle difft man den Output. Aber man kann ihn natürlich auch mit einem Unittest oder dergleichen kombinieren.
_________________ Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut. Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’. Und du schaust mich an und fragst ob ich das kann. Und ich denk, ich werd' mich ändern irgendwann. _________________Farin Urlaub - Bewegungslos
Also ich arbeite seit einiger Zeit in einem ziemlich großen Projektumfeld. Eine Verteilte Plattform mit mehreren Hundert Servern, auf 4 spezifische Plattformen aufgeteilt. Jede Plattform hat 4 Stages (Entwicklung, Test, Systemintegration, Produktion), pro Stage gibt es 1-8 Server, geclustered oder standalone, mit Loadbalancer, Deploymentmanager etc pp.
Da arbeiten mehrere tausend Entwickler summa summarum dran. In meinem Projektteam werden die core-funktionen für alle stages und Plattformen bereitgestellt. Da weiß man nie, wieviele andere Leute das "Zeug benutzen, das man so verzapft". Da sind auch die simpelsten JUnittests wirklich von essentieller Bedeutung. Man merkt es vor allem, wenn ganz banale Sache schief gehen, weil man sie schlicht übersehen hat. Wer an seinem kleinen One-man-projekt arbeitet und irgendwo eine Variable falsch benannt hat und das zur Laufzeit merkt, für den ist es zumeist eine schnelle Sache, das zu fixen. Wenn sowas aber auf einer Systemintegrationsplattform (noch schlimmer Produktion) vorkommt, dann ist es durch geregelte (Notfall-)Deployments ein Aufwand von 2-6 Tagen, diesen Fehler auszumerzen. Der Fehler im Code ist dabei evtl. sogar gleich schnell gefunden und behoben. Nur eben der Rattenschwanz, der sich durch die riesige Umgebung ergibt, kostet ungemein Zeit und damit Geld.
In dem Projekt, in dem ich derzeit arbeite, hat der Kunde sogar Geld in die Hand genommen, um von unserem Team ein Oberflächenbasiertes Testframework auf Seleniumbasis entwickeln zu lassen. Das Framework verwendet am Ende HTML Tests (die man per GUI von Selenium im Browser per Klick aufzeichnen kann, ohne Programmieren können zu müssen) sowie JUnittests und testet damit soziemlich alles, was der Browser kann. Und dann kommt am Ende ein vollständiges Logging mit Sceenshots, XMLCode, HTMLCode, Exceptions etc heraus. Auch da bilden JUnittests im Grunde die Basis. Obwohl viel Komplexere Szenarien denkbar wären, wird das Framework zur Zeit für regressiontests verwendet, um nach einem Deployment die Korrektheit des Systems automatisiert zu verifizieren.
Ich zumindest kenne es so, dass ausnahmslos jede neue Funktionalität durch Tests abgedeckt werden muss. Wir sind zwar noch nicht soweit, dass wir testdriven entwickeln, aber zumindest agile und damit ist testabdeckung Pflicht. Und das ist in jedem Budget einkalkuliert, weil Nachbesserungen aufgrund mangelnder Testabdeckungen am Ende sowieso massiv teurer werden.
Edit: Wir benutzen für unsere Tests: - das Spring TestFramework - Maven (mit Surefire für Testautomatisierung, Cobertura für Codecoverage) und Maven an sich für die Testexecution - Hudson zur Automatisierung der Tests als CI - Selenium für Oberflächentests - JUnit als grundlegendes Testframework
Alles Funktionen bestehen aus einen oder mehreren Fällen. Bei einer Sinus Funktion z.B. gibt es Werte zwischen 0 und 2PI, 0 bis -2PI, über 2PI und unter -2PI. Nun kann man jeden Fall mit einem Test versehen. So sollte bei >+-2PI das gleiche raus kommen wie der Radiant modulo 2PI.
ok, daran hab ich nicht gedacht. Das stimmt natürlich, dass man auch so testen kann (auch wenn das Beispiel der sinusfunktion erneut suboptimal ist. Weil zumindest wenn man´s mit Taylorreihe ausrechnet, bringt man´s sinvollerweise eh in den Bereich -PI/2 bis PI/2, weils da am schnellsten konvergiert. Und ich schätz mal, für andere Näherungsverfahren gilt ähnliches)
Ich glaub so langsam versteh ich, was an den Dingern so nützlich ist. Gibts sowas eigentlich auch für Delphi/pascal? (nicht, dass ich das in meinem aktuellen Projekt nutzen könnte, aber später irgendwann vielleicht)
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Es gibt ein recht brauchbares Testframework von und für Lazarus, basierend auf FPCUnit Test. Das Lazarus-Frontend macht das ganze recht bedienbar. Gibts im Netz genug Dokumentation drüber.
greetings
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Mitglieder in diesem Forum: 0 Mitglieder und 7 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.