Top-Down oder Bottom-Up beim Programmieren?
-
Baba Yaga schrieb:
Gregor schrieb:
Auch die Verknüpfung von Top-Down Planung mit Bottom-Up Implementierung scheint ein interessanter Ansatz zu sein.
Ich finde es nicht ungewöhnlich. Zuerst hat man noch ein grobes Bild vor Augen. Das wird dann während der Planungsphase immer klarer, verdichtet sich, Teilprobleme kristallisieren sich heraus, man fängt an das System in kleinere Einheiten zu zerlegen usw. Wenn dann der Punkt gekommen ist, es in Code zu giessen, beginnen wir sinnvollerweise bei den atomaren Bestandteilen.
Das dachte ich heute mittag auch irgendwann. Aber ich bin mir da niht mehr so sicher. Ja, zuerst hat man ein grobes Bild vor Augen, Top-Down. Und dann plant man rum. Aber beim rumplanen schweife ich auch schnell ab in die Bestandteile und überlege rum, wie die in groben Zügen gehen, ob sie gehen, welche Ausweikungen sie haben, und fummle sie wieder in den Hauptplan ein. Ich schätze, Planen ist nur das grobe Vorwegnehmen des Ausprogrammierens und geschieht nicht notwendigerweise in einer anderen Reihenfolge.
Gregor kann programmieren. Das merkt man gleich, wenn man sich mal mit ihm zankt. Er kann viele treffsichere Argumente aufstellen und einen damit bombardieren.
-
volkard schrieb:
Das dachte ich heute mittag auch irgendwann. Aber ich bin mir da niht mehr so sicher. Ja, zuerst hat man ein grobes Bild vor Augen, Top-Down. Und dann plant man rum. Aber beim rumplanen schweife ich auch schnell ab in die Bestandteile und überlege rum, wie die in groben Zügen gehen, ob sie gehen, welche Ausweikungen sie haben, und fummle sie wieder in den Hauptplan ein. Ich schätze, Planen ist nur das grobe Vorwegnehmen des Ausprogrammierens und geschieht nicht notwendigerweise in einer anderen Reihenfolge.
Ja das stimmt. Gegenseitige Wechselwirkungen und Seiteneffekte sollten immer berücksichtigt werden. Ideal wärs, wenn man sie ausschliessen kann. Leider gelingt das nicht immer. Ein guter Programmierer sollte wenn möglich, wenn er an einen Modul arbeitet, auch das Gesamtkonzept oder einen grossen Teil davon im Kopf haben. Divide et impera ist theoretisch ein guter Ansatz, aber verliert viel von seiner Wirksamkeit, wenn man den Überblick verloren hat.
-
Baba Yaga schrieb:
Ja das stimmt. Gegenseitige Wechselwirkungen und Seiteneffekte sollten immer berücksichtigt werden. Ideal wärs, wenn man sie ausschliessen kann. Leider gelingt das nicht immer.
Hmm.
Baba Yaga schrieb:
Gegenseitige Wechselwirkungen und Seiteneffekte sollten immer berücksichtigt werden.
Sind es nicht die g.W.u.S, die das Planen erst ausmacht?
Ich meine, zum bloßen Runterplanen (rein-planlos nur mit Top-Down) kann ich auch einen Prof nehmen, der nie selber programmiert hat, nur wird das nix.
Was das Planen ausmacht, ist vielleicht, daß man am ersten Tag aus den unzähligen Planungsmöglichkeiten bereits welche ausschließen kann, die einem ein drei Monaten erst das Knie brechen, weil Modul X und Modul Y nicht harmonieren. Oder noch besser von den noch guten Möglichkeiten sieht man eine, daß nach sechs Monaten abkacken wird, weil die Engine es einfach nicht hergeben wird, daß man zufriedenstellend foo und bar machen kann.Was waren denn meine weitsichtigtsen Entscheidungen? Mhhm. Eigentlich immer welche, wo ich das Modul schon recht detailgenau durchüberlegt habe und es paßte einfach nicht zum ganzen Rest. Da geht fühlt man sich dann ganz schlecht. Und bald geht die Warnlampe an und dann hat man auch schnell den technischen Nachweis, daß da dir Kacke am dampfen ist (wobei der Nachweis auch falsch sein kann, weil man ein supi dupi passendes Entwurfsmuster einfach nicht kennt).
-
pointercrash() schrieb:
Gregor schrieb:
Ich finde es sehr interessant, dass es bei dieser Umfrage keinen wirklich klaren Trend zu geben scheint. Alle angegebenen Ansätze scheinen von irgendwelchen Leuten verfolgt zu werden. Auch die Verknüpfung von Top-Down Planung mit Bottom-Up Implementierung scheint ein interessanter Ansatz zu sein. Warum macht man das so? Ich meine, wenn ich etwas Top-Down plane, dann habe ich doch auch eine entsprechende Vorstellung vom Resultat und eigentlich würde ich dann davon ausgehen, dass ich intuitiv auch erst die grobe Struktur realisiere.
Bist Du nur Labertasche oder programmierst Du selber?
volkard schrieb:
Gregor kann programmieren. Das merkt man gleich, wenn man sich mal mit ihm zankt. Er kann viele treffsichere Argumente aufstellen und einen damit bombardieren.
@volkard: Danke!
...aber eigentlich programmiere ich recht wenig. Ich habe in letzter Zeit zwar ein paar tausend Zeilen Code in den Rechner gehackt, aber offensichtlich habe ich immer noch keine wirkliche Systematik beim Programmieren entwickelt. Sonst würde ich solche Fragen, wie ich sie hier stelle, nicht stellen. Außerdem habe ich in letzter Zeit gemerkt, dass mir das Programmieren bei etwas komplizierteren Dingen doch recht schwer fällt und, dass ich viele Fehler mache. Ich habe letztens zum Beispiel den Ball Pivoting Algorithmus zur Oberflächenrekonstruktion zu implementieren. Es hat glaube ich gut 10 Tage gedauert, bis ich den halbwegs fehlerfrei hingekriegt hatte. Deshalb überlege ich, was ich beim Programmieren wohl falsch mache und wie ich gezielter an die Sache herangehen kann. So, dass schnell guter Code herauskommt und ich komplizierte Codeteile bei der Programmierung besser beherrschen kann.
@pointercrash(): Wie gesagt: Ich habe diesen Thread eröffnet, weil ich da bei mir ein vermutlich suboptimales Vorgehen bei der Programmierung festgestellt habe. Ich habe mir auch noch keine wirklich tiefgehenden Gedanken bezüglich des Themas dieses Threads gemacht. Die Antworten, die es in diesem Thread gab, waren für mich aber sehr interessant und ich finde, als Threadersteller muss man so etwas auch irgendwo zum Ausdruck bringen. Und wenn mehrfach ein bestimmter Ansatz genannt wird, der mich etwas überrascht, dann sag ich auch, was mich bezüglich dieses Ansatzes wundert. In dem Zusammenhang verstehe ich zumindest nicht, was das mit "labern" zu tun hat.
Naja, ich hoffe, es kommen noch viele weitere interessante Beiträge zum Thema dieses Threads. Gibt es diesbezüglich eigentlich hilfreiche Literatur?
-
Gregor schrieb:
Ich habe letztens zum Beispiel den Ball Pivoting Algorithmus zur Oberflächenrekonstruktion zu implementieren. Es hat glaube ich gut 10 Tage gedauert, bis ich den halbwegs fehlerfrei hingekriegt hatte. Deshalb überlege ich, was ich beim Programmieren wohl falsch mache und wie ich gezielter an die Sache herangehen kann. So, dass schnell guter Code herauskommt und ich komplizierte Codeteile bei der Programmierung besser beherrschen kann.
Ich habe jetzt nicht so den Eindruck, daß 10 Tage dafür grottenlangsam wären. Mein erster Baum hat viel länger gedauert, aber gut, da war ich kackboon. Meine erste Welt mit dynamischem LOD hat so lange gedauert, das sage ich mal besser nicht, diese verkackte Bäume wiedermal haben sich dauernd so dumm zusammengefaltet, daß Lücken sichtbar waren. Es könnte sein, daß ich allein zum Rollen des Raumschiffs länger gebraucht habe, als 10 Tage.
Vielleicht solltest Du mehr Gamecoders-Foren lesen. Das gibt immer wieder Auftrieb. In Sachen Suche nach Strukturiertheit glaube ich fest daran, daß Du im falschen Loch bohrst. Aber bohr weiter, so tief du kommst, und berichte!
-
volkard schrieb:
In Sachen Suche nach Strukturiertheit glaube ich fest daran, daß Du im falschen Loch bohrst.
Welches Loch hältst Du denn für besser?
-
Gregor schrieb:
volkard schrieb:
In Sachen Suche nach Strukturiertheit glaube ich fest daran, daß Du im falschen Loch bohrst.
Welches Loch hältst Du denn für besser?
a) Nette Bücher lesen. Hast Du schon ein nettes über Xtreme Pr0gramming gelesen? (edit: Nicht den Wikipedia-Artikel lesen! Davon wird man blind. Er pervertiert die Sache, dann lieber sich von Prof84 erklären lassen, wie man Kühe melkt.)
b) Drogen essen. Ähnlich gut kann sein, Die Quelle in der S-Bahn, die Du nur zu diesem Zweck benutz, zu lesen, sich zum Lesen zu zwingen, und nicht nur halbherzig, obwohl junge Arbeitslose mit Kampfhunden, die es nicht mehr gibt, neben einem stehen.
c) C++ natürlich und Struppis Literaturhinweise, die OO-lastige SOftwareentwicklung zeigen und nicht gerade in Richtung Shlaer-Mellor!
Nee, dazu kenne ich Dich dann doch zu wenig. Alles nur Spekulation. Ich denke, a) fehlt Dir tatsächlich. Aber sonst? Wie kriege ich mein Kind dazu, nicht an Gott zu glauben? Das kann ich nicht. Wie kriege ich Dich dazu, nicht an Formalismen zu glauben? Das kann ich auch nicht.
-
volkard schrieb:
Gregor schrieb:
volkard schrieb:
In Sachen Suche nach Strukturiertheit glaube ich fest daran, daß Du im falschen Loch bohrst.
Welches Loch hältst Du denn für besser?
a) Nette Bücher lesen. Hast Du schon ein nettes über Xtreme Pr0gramming gelesen?
b) Drogen essen. Ähnlich gut kann sein, Die Quelle in der S-Bahn, die Du nur zu diesem Zweck benutz, zu lesen, sich zum Lesen zu zwingen, und nicht nur halbherzig, obwohl junge Arbeitslose mit Kampfhunden, die es nicht mehr gibt, neben einem stehen.
c) C++ natürlich und Struppis Literaturhinweise, die OO zeigen und nicht gerade in Richtung Shlaer-Mellor.
Nee, dazu kenne ich Dich dann doch zu wenig. Alles nur Spekulation. Ich denke, a) fehlt Dir tatsächlich. Aber sonst? Wie kriege ich mein Kind dazu, nicht an Gott zu glauben? Das kann ich nicht. Wie kriege ich Dich dazu, nicht an Formalismen zu glauben? Das kann ich auch nicht.Keine Angst, ich folge Formalismen nicht blind. ...zumindest nicht dauerhaft, höchstens als Zwischenstufe.
zu a) XP ist natürlich ein Ansatz. Ich habe vor langer Zeit mal etwas in ein entsprechendes Buch hineingeguckt und habe auch ein Praktikum in der Uni mitgemacht, in dem nach XP vorgegangen wurde. Ich setze es allerdings nicht ein. Habe das irgendwie aus den Augen verloren. Vielleicht wäre es aber ganz gut, einige der dortigen Techniken in meine Codeentwicklung einfließen zu lassen. Vielleicht sollte ich mir auch mal einige andere Bücher zu Softwareentwicklungsmethodiken ansehen. Vielleicht habe ich das Thema bis jetzt nicht ernst genug genommen. Ich sollte mal gucken, ob XP auch Aussagen zu genau dem Thema dieses Threads macht.
zu b) Das Lesen der speziellen Literatur interpretiere ich mal als "Bring Dich in eine Position, in der Du Deiner Aufgabe fachlich überlegen bist!". Das ist sicherlich ein Punkt, der mich etwas aufgehalten hat. Gerade, wenn man mathematisch der Sache bei solchen Algorithmen nicht komplett überlegen ist, braucht man doch recht lange, um die entsprechenden Codeteile zu implementieren. Das hat mich auch etwas aufgehalten und hat die Reihenfolge der Codeentwicklung beeinflusst. Ich habe die entsprechenden Codeteile, wenn ich sie auf den ersten Blick nicht überblickt habe, erst am Schluss implementiert. Naja, der Hauptgrund, warum das 10 Tage gedauert hat, war aber, dass das Debugging wirklich lange gedauert hat. Sicherlich die Hälfte der Zeit. Und das waren eigentlich keine mathematischen Fehler, sondern Fehler im Programmfluss. "Nicht bedachte Fälle", "etwas falsche if-Bedingungen" und so weiter. Ich vermute, solche Fehler im Programmfluss sind mindestens teilweise eine Folge einer schlechten Programmierweise.
zu c)
-
Standardanwendungen kriegst Du mit Standardvorgehen gut hin.
-
Gregor schrieb:
Keine Angst, ich folge Formalismen nicht blind. ...zumindest nicht dauerhaft, höchstens als Zwischenstufe.
zu a) XP ist natürlich ein Ansatz...Ich sollte mal gucken, ob XP auch Aussagen zu genau dem Thema dieses Threads macht.
Das meinte ich nicht so. Es scheint, Du würdest Du in Erwägung ziehen, Dir aus einigen XP-Tricks ein Kochrezept zusammenzubauen. Die Tricks sind Anti-Tricks, nur viel besser verpackt.
Gregor schrieb:
zu b) Das Lesen der speziellen Literatur interpretiere ich mal als "Bring Dich in eine Position, in der Du Deiner Aufgabe fachlich überlegen bist!". ..."etwas falsche if-Bedingungen" und so weiter. Ich vermute, solche Fehler im Programmfluss sind mindestens teilweise eine Folge einer schlechten Programmierweise.
Das meinte ich nicht so. Es gibt gewisse Geisteszustände, die jenseits des rein Rationalen sind. Wer kennt das nicht, daß man beim Duschen oder beim Kacken auf die grandiosesten Programmierideen kommt?
Gregor schrieb:
zu c)
Das meinte ich nicht so. Sein "C++ Die Programmiersprache" behandelt ein wenig mehr als nur C++ und die Literaturhinweise beim DingenserstellenUndPlanen sind gut, finde ich. Wenn ich mich recht erinnere, zeigt er da auf nicht ein C++-lastiges Buch.
-
Gregor schrieb:
Nach welchem Ansatz geht Ihr beim Programmieren vor? Programmiert Ihr erst auf einem relativ abstrakten Level, um dann später in die Details zu gehen (Top-Down)? Oder programmiert Ihr erst die Details und fügt sie nachher zu einem Ganzen zusammen (Bottom-Up)? Oder macht Ihr es mal so und mal so?
Beides und weder noch. Beim Programmieren (Coden) würde ich sagen ist es uninteressant. Beim Planen dessen was man Programmieren will könnte man zwischen Bottom-Up und Top-Down unterscheiden, aber auch nicht so wirklich. Es gibt wohl keinen der bei ner Schleife anfäng und daraus ein Programm macht, ohne zu wissen, was er eigentlich für ein Programm will. Und da sieht man auch schon was man plant. Das, was man nicht weiß. Will man nen Tetris-Klon programmieren, muss man nicht mehr planen, was Tetris machen soll, weil man das Spielprinzip kennt. Willst du ein Content-Business-Controlling-Management-System(TM) programmieren, musst du erst mal wissen und planen was das Ding machen soll, aber das unten ne Datenbank hin kommt und wie die funktioniert, ist schon klar.
Willst du irgend ein bestehendes System erweitern, musst du das bestehende System kennen(lernen) und planst dann irgendwo mittendrin. Am Schluss validierst du nochmal Bottom-Up und Top-Down und baust es ein. Bei der Umsetzung von nem (Ball Pivoting) Algorithmus würde ich nicht sagen, dass es um Bottom-Up oder Top-Down geht, sondern darum zu verstehen, wie der Algo im Detail funktioniert und beim Programmieren merkt man dann, dass man manche Details nicht verstanden hat. Allgemein hilft die simple Erkenntnis, dass man Dinge verstehen sollte, bevor man sie zusammen baut, ungemein, um schneller zum Zeil zu kommen, egal ob Oben, Unten oder in der Mitte. Man kommt auch zum Zeil, wenn man nicht alles verstanden hat, aber meistens braucht man länger und es wird nicht so gut. Bis man aber so weit ist, dass man alles versteht, braucht man nocht viel länger. Alles klar? 
-
Bei der Implementation eiens Algorithmus gehe ich auch völlig anders vor. Meiner Meinung nach kann man einen komplexen Algorithmus nicht implementieren, wenn man ihn nicht vollständig verstanden hat. An dem Punkt gehts auch nicht mehr um Top-Down oder Bottom-Up weil man nichts mehr planen muss. der Algorithmus selbst ist bereits das Resultat einer Planung, die Aufgabe des Progrmamierers ist jetzt nur noch, diesen Plan zu verstehen. Bei Algorithmen gehe ich demnach so vor:
1. Algorithmus verstehen
1.a. versuchen den Algorithmus jemandem zu erklären um sich selbst zu beweisen, dass man ihn verstanden hat
1.b. Code einer Implementierung an Land ziehen und versuchen, DIE zu verstehen.
2. zu verwendende Datenstrukten bestimmen
3. Datenstrukturen implementieren, wenn nicht vorhanden
4. Algorithmus runterprogrammieren.
-
Was versteht Ihr eigentlich unter Planung?
Ich meine, ich mache das eigentlich gar nicht. Zumindest betreibe ich keine explizite Planung. Bei mir sieht Planung so aus:
1. Ich lese etwas über den Algorithmus oder definiere mir anderweitig mein Programmierziel.
2. Ich schlafe.
3. Die grobe Klassen- und Algorithmenstruktur hat sich von selbst in meinem Kopf gebildet. Ich setze jeweils das um, bei dem mir auch die Details sofort klar sind. Nur bei sehr komplizierten Dingen mache ich mir nochmal explizite Gedanken. Stift und Papier benötige ich eigentlich nur, wenn irgendwo ne Menge Mathematik drinsteckt, die ich nicht einfach so aus dem Ärmel schütteln kann.Mit anderen Worten, eine explizite Planung gibt es bei mir eigentlich nicht. Damit kriege ich durchaus relativ komplizierte Dinge hin, aber ich merke so langsam, dass ich damit an meine Grenzen komme. Deshalb suche ich momentan nach etwas Systematik beim Programmieren.
@volkard: Ok, Formalismen sind kein Allheilmittel, aber ich verstehe sie als Werkzeuge. Werkzeuge, um Komplexität zu beherrschen. Ich denke, es gibt Situationen, in denen es gut ist, ein Konzept zu haben, nach dem man vorgeht. Ein Konzept, auf das man sich im Zweifelsfall zurückziehen kann. Dieses Werkzeug fehlt mir bei der Programmiermethodik momentan.
-
Macht eine strikte Trennung überhaupt Sinn? Ich gehe eigentlich so vor, dass ich mir vorher grob überlege, welche Teile es gibt, was man braucht und wie das alles zusammen hängt (Top-Down). Aber beim programmieren fange ich dann in der Regel "unten" an (Bottom-Up). Gerade wenn man sich in einem Gebiet nicht gut auskennt, übersieht man beim planen oft Details. Außerdem habe ich gerne etwas, was man schon benutzen/testen kann. Natürlich erfordert dieses Vorgehen auch regelmäßig Refactoring.
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Neuigkeiten aus der realen Welt in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Top-Down programmieren kann man eigentlich erst dann richtig wenn man genug Erfahrung mit dem hat was man realisieren möchte.
Damit würde ich sagen das Top-Down eher die theoretische Seite des programmierens ist und Bottom-Up die Praktische. Natürlich nicht absolut getrennt.Als Beispiel eine Engine mit DirectX: Man sieht leider erst zu spät, dass man wesentlich mehr vorher hätte Planen müssen. Die Planung war aber nicht möglich, weil einem dazu die Erfahrung mit DirectX gefehlt hat.
Es kommen Dinge -die berücksichtig wurden- aber nicht im Detail bekannt waren(verwaltung von Texturen, Mathematik, Buffer, welchselwirkung von Direct3D und DirectInput) und die dann nicht mehr in die bereits vorhandene Struktur reinpassten. Die Folge davon war eine Neustrukturierung und eine weitreichendere Planung. Also ein wechsel von Top-Down und Bottom-Up(mit Frustmomenten wenn man merkt es geht so nicht mehr weiter).Meiner Meinung nach kommt man nicht drum herum am anfang Bottom-Up zu programmieren um Erfahrung zu sammeln, damit man dann später "neu" anfängt, aber dann Top-Down.
Je mehr Erfahrung man gesammelt hat, desto länger wird die Top-Down Phase.Hab irgendwo mal gelesen, dass die kreativen Menschen unter uns eher Top-Down programmieren und die Analytischen Bottom-Up und Genies keine Bevorzugung haben. Ich würde mich zu den Analytikern zählen(was oft genug kein Vorteil ist!).
-
Gregor schrieb:
Naja, der Hauptgrund, warum das 10 Tage gedauert hat, war aber, dass das Debugging wirklich lange gedauert hat. Sicherlich die Hälfte der Zeit. Und das waren eigentlich keine mathematischen Fehler, sondern Fehler im Programmfluss. "Nicht bedachte Fälle", "etwas falsche if-Bedingungen" und so weiter. Ich vermute, solche Fehler im Programmfluss sind mindestens teilweise eine Folge einer schlechten Programmierweise
Zu viel Zeit beim Debuggen zu brauchen ist meistens ein Zeichen dafür, dass man zu wenig bzw. gar keine Unittests geschrieben hat. Trifft dies zu?
Ich stimme Volkard vollkommen zu: Literatur zu Agiler Entwicklung und Extreme Programming würde Dich sicherlich weiterbringen. Unittests sind einer der zentralen Bestandteile von XP und grade für komplexere Algorithmen in meinen Augen absolut unerlässlich!! Ich weiss, dass es nicht immer einfach ist, Unittests zu schreiben, vor allem bei Grafikprogrammierung. Das sollte Dich aber nicht davon abschrecken, Dich damit zu beschäftigen.
Debugging ist manuelles Testen => unstrukturiert. Unittests sind automatisches Testen => strukturiert! Mit Debugging testest Du immer nur einen bestimmten Fall. Sobald Du Code änderst, müsstest Du eigentlich alle Fälle nochmal testen. Das tust Du aber idR beim manuellen Testen mit Debugger nicht, weil es kaum handlebar ist. Unittests dokumentieren ALLE Testfälle. Es ist viel einfacher, für alle Bedingungen des Algorithmus, Testfälle zu erzeugen als diese manuell im Debugger zu testen. Der große Vorteil: nach jeder Codeänderung drückst Du einfach nur auf eine Taste und hast sofort das Feedback. Und vor allem helfen die Unittests auch später beim Warten des Codes ungemein. Man merkt sofort, wenn irgendeine Codeänderung oder ein Refactoring unschöne Seiteneffekte hat.
Debugging ist wichtig, aber Unittests sind wichtiger, vor allem bei komplizierten Algorithmen.
Edit: Der Vollständigkeit halber sei hier noch TDD (Test Driven Development) erwähnt, eine Methodik, die noch einen Schritt weiter geht und das Prinzip "Tests first" progragiert (bedeutet: Unittests schreiben, bevor man überhaupt den zu testenden Code schreibt).
-
Ich bin von übermäßigem Testen wieder abgekommen.
Es gibt Module, die nach automatisierten Tests betteln, rohes Numbercrunching, Containerklassen,...
Und es gibt Sachen, die sich dem Testen eher entziehen, grafische Ausgabe, KI,...
Und einen dicken Algo wie diesen kann man am Ende nur testen, indem man ihn einmal fertig hat und dann Eingaben und Ausgaben zusammen abspeichert und damit automatisiert gegen Kaputtgehen schützt.
Ich sehe jetzt nicht, wo Gregor offensichtlich durch zu wenige Unittests sich einen Zeitgewinn duch die Lappen gehen ließ. (<- Ha, da ist also das "ließ" her, das "ließ" von "ließ ein buch"!)
-
Ich galub ja, die Unittest-Idee stammt von nem Programm-mit-Datenbank-Entwickler. Da funktionieren die auch wunderbar. Bei grafiksachen Sachen (Ray-Tracer...) würde ich wenn überhaubt, automatische funktionale Tests verwenden.
-
Operationen mit rein grafischem Output lassen sich in der Tat schwer automatisiert testen. Aber idR manipuliert der zu testende Code ja irgendwelche Datenstrukturen und sowas lässt sich somit ganz gut unittesten. Häufig sind Entwickler einfach nur zu faul (mich eingeschlossen
), den Overhead auf sich zu nehmen. Das definieren der Testfälle ist ja nicht das Problem (macht man indirekt beim manuellen Testen auch -> Debugger, Logs, Oberfläche). Nervig und zeitraubend ist meistens das Erzeugen der Testdaten, wenn die Datenstrukturen komplex sind.GUI oder 2D Zeichencode teste ich auch nicht automatisiert. Das lässt sich imo relativ gut manuell testen, da visuell sichtbar - und Fehler bleiben selten lange unbemerkt.
Zeichnen in 3D ist nicht so mein Metier, aber sofern man mit nem Scenegraph arbeitet, liegt ja auch da eine Datenstruktur zugrunde, deren diskrete Werte sich mit Asserts erfassen lassen. Da fehlt es mir aber an praktischer Erfahrung. Würde mich mal interessieren, ob und wie professionelle 3D Programmierer testen!?