Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: So Jul 13, 2025 09:32

Foren-Übersicht » Programmierung » Allgemein
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 26 Beiträge ]  Gehe zu Seite Vorherige  1, 2
Autor Nachricht
BeitragVerfasst: Mo Jan 03, 2011 13:33 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 11, 2009 08:02
Beiträge: 532
Programmiersprache: pascal (Delphi 7)
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 :lol:

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 :roll:


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Jan 03, 2011 13:44 
Offline
Forenkatze
Benutzeravatar

Registriert: Mi Okt 22, 2003 18:30
Beiträge: 1945
Wohnort: Närnberch
Programmiersprache: Scala, Java, C*
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'."


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Jan 03, 2011 14:12 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
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.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Jan 03, 2011 14:32 
Offline
Forenkatze
Benutzeravatar

Registriert: Mi Okt 22, 2003 18:30
Beiträge: 1945
Wohnort: Närnberch
Programmiersprache: Scala, Java, C*
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'."


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Jan 03, 2011 15:31 
Offline
DGL Member
Benutzeravatar

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Jan 03, 2011 15:33 
Offline
Forenkatze
Benutzeravatar

Registriert: Mi Okt 22, 2003 18:30
Beiträge: 1945
Wohnort: Närnberch
Programmiersprache: Scala, Java, C*
So mal rein der Neugierde halber: Wie sieht's mit Code Coverage Tools bei C# aus?

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Jan 03, 2011 15:36 
Offline
Guitar Hero
Benutzeravatar

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


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Jan 03, 2011 16:51 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL
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


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Jan 03, 2011 17:38 
Offline
DGL Member

Registriert: So Aug 20, 2006 23:19
Beiträge: 564
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


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Jan 03, 2011 18:58 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 11, 2009 08:02
Beiträge: 532
Programmiersprache: pascal (Delphi 7)
Zitat:
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)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Jan 03, 2011 19:36 
Offline
DGL Member
Benutzeravatar

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 networkmy 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


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 26 Beiträge ]  Gehe zu Seite Vorherige  1, 2
Foren-Übersicht » Programmierung » Allgemein


Wer ist online?

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.

Suche nach:
Gehe zu:  
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.009s | 14 Queries | GZIP : On ]