Schlagwort-Archive: unit tests

Dev-Blog Donnerstag 5/16

Dev-Blog Donnerstag 5/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Das Ressourcen-Update ist durch, der erste große Teil des Refactorings damit abgeschlossen. Trotzdem ist in dem Bereich noch einiges zu tun.

Neben kleineren Code-Reviews, die wir nun ziemlich konsequent durchziehen, haben wir noch das ein oder andere Brainstorming Ticket diskutiert – also etwas in unserem Ideenpool (Redmine 🙂 ) geplantscht.

Ansonsten war ich vergangene Woche eher ein Gefangener des rL.

[Iwan (shlainn)]

Der neue Ressourcen-Unterbau, der uns einiges an Blut, Schweiß und Tränen gekostet hat, ist online. Ebenso ist ein Dorn den ich schon immer im Auge hatte, nämlich das Verhalten beim Beladen von Flotten, auch beseitigt. Eine gute Woche.

Die Flottenbeladung war bislang so gebaut, dass sie immer ein Schiff nach dem Anderen vollgemacht hat. Das führt natürlich dazu, dass wenn man nur mal kurz 1000 Holz mit einer Flotte von 20 Mega-Raumern verschiffen wollte, alles Holz in den ersten Raumer geladen wurde, und 19 Stück leer mitgeflogen sind. Das neue System verteilt die Lade- und Entladearbeiten geschickt auf alle Schiffe, sodass in einem Fall wie dem gerade beschriebenen, die Ladezeit durch paralleles Laden in alle Schiffe deutlich verkürzt wird.

Wir sind immer bestrebt unser Sortiment an Werkzeugen die wir im Hintergrund für die Entwicklung von eXperinox verwenden zu erweitern, sodass unsere Dev-Pipeline immer effizienter wird. Neben den von Horst schon mehrfach erwähnten automatisierten Unit-Tests (phpUnit) auf unserem Jenkins-Buildserver verwenden wir auch Code-Style-Checker (phpcs & PHPCheckStyle – ja das sind zwei unterschiedliche Programme :p ) um den Code zu analysieren und auf potentielle Probleme aufmerksam gemacht zu werden.

Zusätzlich dazu habe ich mir Codeception angesehen – ein Testing-Framework auf der Basis von phpUnit, dass es einfacher macht Acceptance tests durchzuführen – über einen Browser automatisiert bestimmte Aktionsfolgen an einen Test-Server mit eXperinox zu schicken, und sicherzustellen, dass jeder Click noch die gewünschte Aktion nach sich zieht.  Das ist etwas, das mit phpUnit auch möglich, aber eher umständlich ist. Wenn Codeception hält, was es verspricht, wäre das ein weiterer Schritt in eine gute Richtung für eXperinox.

Dev-Blog Donnerstag 4/16

Dev-Blog Donnerstag 4/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Ich beginne jetzt nicht damit, dass ich wieder UnitTests geschrieben habe. Ab sofort könnt ihr davon ausgehen, dass ich jede Woche den ein oder anderen Test schreibe. Das sind wir der steigenden Anzahl der Spieler einfach schuldig. Denn klar ist: mehr Tests erhöhen die Qualität. Punkt.

Und wer sich fragt, was denn aus dem Kampfsimulator geworden ist, den ich mit Construct umsetze, den muss ich etwas vertrösten. Das Projekt liegt vorübergehend auf Eis. Der Ressourcen-Umbau und die geplanten Features für das „Hauptspiel“ eXperinox lassen das im Moment nicht zu.

Ganz im Umbaufieber gefangen, baue ich nun auch die Bauqeues für Raumschiffe und Gebäude um. Passt recht gut zum Ressourcenumbau dazu.

[Iwan (shlainn)]

Das Beladen von Raumschiffen war mir schon immer ein Dorn im Auge. Da hat man eine Flotte von 50 Mega-Raumern, will mal eben 1000 Holz von A nach B fliegen, und anstatt 20 Holz in jeden Raumer zu packen und in Sekunden fertig zum Abflug zu sein, dauert das Beladen 4 Minuten, da die gesamte Ladung nur in den ersten Raumer geladen wird, und die anderen 49 gelangweilt herumhängen. Doch Rettung ist nah! Diese Woche habe ich einen ersten Vorstoß zu einer Verbesserung des Ladeverhaltens unternommen. Diesen werden wir jetzt erst einmal ausgiebig intern testen.

Der Ressourcenumbau in dem wir derzeit stecken wurde ausgelöst durch den Einbau der Handelsstationen, und dient schlussendlich dem Ziel, dieses Feature besser in unsere bestehende Code-Basis zu integrieren – denn zwei parallele Systeme (eines für Ressourcen an Kolonien der Spieler und eines für Handelsstationen) für die gleichen Aufgaben zu haben steigert unnötig die Komplexität des Codes. Und Handel ist auch, wenn alles gut geht, der nächste Punkt auf meiner ToDo-Liste: die vor einiger Zeit angekündigten Verbesserungen rund um Kaufaufträge stehen an 🙂

Dev-Blog Donnerstag 3/16

Dev-Blog Donnerstag 3/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Wer das Wort UnitTests schon nicht mehr hören kann, ich habe wieder einige erstellt 🙂 . Aktuell waren die Bau-Queues für Raumschiffe und Gebäude an der Reihe. Ein recht zentraler Teil in eXperinox, dem etwas „Liebe“ nicht schaden kann. Das bedeutet Refactoring (merciless, wie immer), um den Code an unsere immer höheren Ansprüche anzupassen. Und bevor man etwas umbaut, sollte man eben (weghören) zuerst UnitTests schreiben. Denn auch wenn UnitTests niemals alle möglichen Fehler aufdecken können – speziell bei einem Refactoring helfen sie schon ungemein.

Der Umbau des Ressourcen-Handlings (näheres siehe Dev-Blog von letzter Woche) hat große Fortschritte gemacht, die neue Lösung fühlt sich nun sehr gut an. Hier haben Iwan und ich wieder einmal bewiesen, dass wir uns gegenseitig zu Höchstleistungen anspornen und gemeinsam eine klar bessere Lösung aus dem Hut zaubern, als es ein einzelner tun könnte. Aber das ist ja nichts Neues: Pair-Programming und gemeinsame Code-Reviews steigern die Qualität eines Sources-Codes.  Zwei Gehirne denken besser, 4 Augen sehen mehr 🙂 .

Und ganz nach unserem gelebten Motto, dass wir gerne Wünsche unserer Spieler erfüllen, habe ich diese Woche einen davon sehr kurzfristig umgesetzt. Nämlich, dass Spieler einer Union Heimatplaneten eines ihrer Mitglieder auch während des Einsteigerschutzes anfliegen können, zum Beispiel, um sie anhand eines Transportes mit Ressourcen versorgen zu können. Anfrage im Chat gegen 1715, online ging das Feature schon eine Stunde später 🙂 .

[Iwan (shlainn)]

Ich habe mich eines alten Feindes angenommen: der Touch-Bedienung unserer 3D-Karte. Vor knapp zwei Jahren als ich die ursprüngliche Version der Karte schrieb, war die Welt noch einfacher, touch-Unterstützung noch nicht standardisiert, und ich war ehrlich froh, dass das Ding überhaupt läuft. Heute, 2016, hat man keine Ausreden mehr nicht zumindest simple Unterstützung für touch anzubieten. Und so sprang ich diese Woche über meinen Schatten.

Das Auswählen von Objekten in der Karte ist jetzt deutlich zuverlässiger, man kann die Karte durch wischen verschieben, und auch einfache Multi-touch Features wie das Drehen der Karte durch Wischen mit zwei Fingern und Zoomen mittels Kneif-Geste (heißt das so? Iwan ist verwirrt) sind eingebaut. Derzeit durchläuft der Code interne Tests, aber mit etwas Glück ist er, wenn dieser Beitrag online geht schon im Spiel und macht das Leben von Spielern an mobilen Endgeräten einfacher.

Dev-Blog Donnerstag 2/16

Dev-Blog Donnerstag 2/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

UnitTests, UnitTests, UnitTests. Ich bin wieder auf den Geschmack gekommen und schreibe nun wieder vermehrt UnitTests. Vor allem, seit ich seit der Coverage-Analyse von Jenkins nun weiß, dass es mit unserer Testabdeckung noch etwas schlechter aussieht, als kürzlich hier behauptet. Nicht etwas mehr als 35% sind es, sondern nur schlappe 26%. Warum der Unterschied? Naja, Statistiken, man weiß ja – nur wer sie selber fälscht, kann sie korrekt interpretieren  😉 .

Bei der ersten Coverage-Analyse wurden Klassen ausgeklammert, die 0% Abdeckung hatten. Diese sind nun mit berücksichtigt und verschlechtern somit unseren ohnehin üblen Wert noch weiter.

Dann habe ich mich vergangene Woche wieder einmal etwas intensiver mit Transaktionen, Isolationslevel und Deadlocks beschäftigt. Unser Code braucht an der ein oder anderen Stelle in diesem Zusammenhang auch noch etwas Refactoring.

Auch im Zusammenhang mit den Ressourcen haben wir weiteren Handlungsbedarf ausgemacht und uns in eines der gnadenlosesten Refactorings Ever! Ever! Ever! gestürzt.

Die Konsolidierungsphase hält also noch etwas an.

[Iwan (shlainn)]

Das schreiben von Code ist ein iterativer Prozess.

Als wir den Handel implementiert haben, wurde deutlich, dass unser bisheriger Ressourcenhandling-Code nicht ohne weiteres an die neuen Anforderungen angepasst werden kann – und ich habe einen neuen ResourceManager geschrieben, der neben den bisherigen Fähigkeiten auch mit Ressourcen in Handelsstationen umgehen konnte und einige weitere Verbesserungen brachte. Zunächst haben wir den neuen Code nur für Handelsstationen eingesetzt, um sicherzugehen, dass alles auch in der realen Umgebung unseres Spiels (und nicht nur in UnitTests) so funktioniert wie es soll. Das war vor Weihnachten.

Letzte Woche haben wir dann begonnen auch im Rest des Spiels den ResourceManager einzubauen – und dabei fielen Sonderfälle auf, in denen Ressourcen verloren gehen könnten, wenn wir den neuen Code einsetzen – sodass Horst eine zweite Version des ResourceManagers schrieb, welche die Probleme behob. Bei weiterer Analyse fiel uns dann aber auf, dass dadurch auch eine der Verbesserungen aus der ersten Version verloren ging. Nach längerer intensiver Diskussion krempelten wir dann das Design noch einmal komplett um – und sind jetzt bei der dritten neuen Version des Ressourcen-Codes.

Diese Version haben wir jetzt überall eingebaut und testen in den nächsten Tagen intensiv, bevor wir sie online stellen. Ressourcen sind ein äußerst wichtiges Thema, und Ressourcen die durch Bugs verloren gehen (oder durch Exploits unrechtmäßig gewonnen werden können) sind für Spieler, und uns als Spielebetreiber, extrem ärgerlich und frustrierend – und das wollen wir um jeden Preis vermeiden.

 

Dev-Blog Donnerstag 1/16

Dev-Blog Donnerstag 1/16

Von Entwicklern für Entwickler

[Horst (Slayer)]

Eine herausfordernde Woche liegt hinter uns. Mehr Spieler bedeutet zum einen, mehr Zeit für die Betreuung der Community aufwenden zu müssen (oder zu dürfen, denn mir macht das auch sehr viel Spaß) und zum anderen, dass Bugs durch mehr aktive Spieler nun viel schneller an Tageslicht kommen.

Unser Logging hat sich in dem Zusammenhang auch als etwas zu „chatty“ herausgestellt, so manchen Log-Level habe ich deshalb angepasst, damit wirklich wichtige Log-Einträge nicht drohen in der Menge unterzugehen.

Auch das Thema Performance poppt nun wieder auf. Insbesondere im Zusammenhang mit der Datenbank, kann das durch viele gleichzeitige Aktionen zu unangenehmen Situationen führen. Da gilt es nun, ein sehr wachsames Auge drauf zu haben. Bevor wir nun aber etwas refactoren, haben wir uns vorgenommen, für die betroffenen Klassen zuerst UnitTests zu schreiben. So ist auch diese Woche wieder der ein oder andere Test entstanden. Wie wir in Zukunft in dem Zusammenhang einen wichtigen Schritt vorwärts machen, beschreibt Iwan weiter unten.

Der Ingame Chat tut im Zusammenhang mit den neuen Spielern sehr gute Dienste, da er gut angenommen wird, um dort Tipps von „alten Hasen“, also Spielern, die schon länger spielen, zu bekommen. Und wir haben so die Möglichkeit, aktiv nach Problemen zu fragen und sofort einzugreifen, wenn es wo hakt. Auch der Blick „über die Schulter“ unserer Spieler bringt uns wichtige Erkenntnisse im Rahmen von potentiellen Einstiegshürden.

[Iwan (shlainn)]

Vor einer Weile haben wir einen Server für interne Aufgaben angeschafft. Bislang langweilt sich dieser etwas – er ist nur für das tägliche Backup der Datenbanken unserer verschiedenen Spiele verantwortlich. Zeit dies zu ändern.

Horst berichtet ja seit einer Weile über unser Dauerprojekt, möglichst viel vom eXperinox-Code durch automatisierte Tests abgedeckt zu haben. Das hilft, bei Veränderungen Fehler zu vermeiden – manchmal ist es bei historisch gewachsenem Code schwierig alle Stellen, an denen eine Änderung Einfluss hat, zu erkennen. Aber Unit Tests haben den „Nachteil“ dass man sie auch ausführen muss, sonst bringen sie nichts – und jeder weiß: Entwickler sind faul. Daher habe ich mich diese Woche mit verschiedenen Continuous Integration Tools beschäftigt.

Der Elefant im Raum ist Jenkins – ein Java-basiertes Tool, das ALLES kann. Und für das was es nicht kann, gibt es Plugins. Es ist auch notorisch kompliziert aufzusetzen, weshalb ich mich zunächst auf die Suche nach Alternativen begeben habe.

Eine solche Alternative ist PHPCI. Dieses Tool ist rein in PHP geschrieben, benötigt also keine zusätzliche Software auf dem Server, und bringt häufig genutzte Tools in der PHP-Entwicklung wie PHPUnit, PHP Mess Detector, PHP Code Sniffer und einige weitere im Installationspaket mit. Verwaltet wird das ganze, wie auch Jenkins, über den Browser.  Die Installation ist sehr einfach und relativ gut dokumentiert – nach einer halben Stunde hatte ich das Paket installiert, konfiguriert, eXperinox als Projekt hinzugefügt, und einen ersten Build mit Tests laufen lassen. Leider ist die Ausgabe etwas enttäuschend – ich konnte nicht einsehen, welche Tests erfolgreich gelaufen sind, oder wie viel von unserem Code bereits durch Tests abgedeckt ist. Diese Informationen sind sehr wichtig, um zu verstehen, wo wir am dringendsten nachbessern müssen.

Also zurück zu Jenkins. Ich muss vorab ein Geständnis machen: Ich bin Jenkins gegenüber etwas voreingenommen, da meine bisherigen Erfahrungen mit Java, egal ob auf dem Server oder als Client-Software, durchgehend unerfreulich waren – abgesehen von den Sicherheitslücken, die in regelmäßigen Abständen bekannt werden. Erfreut konnte ich jedoch feststellen, dass es einen Docker Container für Jenkins gibt, in dem alles feinsäuberlich verpackt ist – keine Installation, keine Java-Kontamination im System! Erste lokale Tests verliefen auch vielversprechend – doch dann stellte sich heraus dass Docker auf unserem Server nicht funktioniert (GRR Server4you vServer!). Also doch auf die klassische Art. Dankbarer Weise hat Marc Harter von StrongLoop (node.js) ein zweiteiliges Tutorial zur Einrichtung von Jenkins  verfasst, das den Prozess enorm erleichtert hat. Der langen Geschichte kurzes Ende ist, dass jetzt jedes Mal, wenn wir Codeänderungen in unser Git-Repository schieben, ein vollständiger Durchlauf der Unit Tests durchgeführt wird – und wir bei Fehlern in den Tests benachrichtigt werden.

screenshot113

Willkommen in der Zukunft, eXperinox!

Natürlich könnte Jenkins noch viel mehr, aber wir wollen uns langsam an die Materie herantasten und das System an unsere Bedürfnisse anpassen.

 

Dev-Blog Donnerstag 52/15

Dev-Blog Donnerstag 52/15

Von Entwicklern für Entwickler

[Horst (Slayer)]

Nachdem wir letzte Woche unsere UnitTests auf Iwans internen Server eingerichtet haben, waren noch ein paar kleine Nacharbeiten erforderlich, damit am Ende alle 226 Tests (zu wenig, wie schon öfter erwähnt) durchlaufen. Aber immerhin – laut Code Coverage Report werden knapp 38% unserer Business-Logik abgedeckt. Und für 2016 haben wir uns vorgenommen, den UnitTests wieder mehr Aufmerksamkeit zu schenken.

Code Coverage unserer Business Logik
Code Coverage unserer Business Logik

 

Pimp my Log, wie im letzten Blog beschrieben, läuft einwandfrei. Ein klarer Fortschritt in unserer Infrastruktur. So haben wir unsere Traces ständig auf einfache Art und Weise im Blick.

Die letzten Änderungen am Dialog zur Flottenzusammenstellung haben mich auch in Kontakt mit einem recht alten Javascript-File gebracht. Schön, wenn man das Gefühl hat, dazugelernt zu haben. Oder anders ausgedrückt: schöner Code ist etwas anderes, ein weiteres Refactoring war die Konsequenz.

Frohe Weihnachten und schöne Feiertage!

[Iwan (shlainn)]

Ah, endlich eine Woche Freizeit für eXperinox! Und so haben wir heute, an Weihnachten, wie versprochen eine erste Version des Handels zwischen Spielern online gestellt.

Die Details dazu, wie der Handel abläuft habe ich schon recht ausführlich im Forum beschrieben. Die aktuelle Version soll als Grundlage für die weitere Entwicklung von Features rund um den Handel dienen. Wir haben uns hier, wie schon beim Profil entschieden, zunächst eine Grundversion online zu stellen, und diese dann iterativ zu erweitern. Zum Einen gibt uns das bereits jetzt die Möglichkeit, wertvolles Feedback von Spielern in die Entwicklung einfließen zu lassen. Außerdem ist es für uns deutlich einfacher, kleinere Stücke online zu stellen, anstatt ein großes Monster-Feature wie das Baumenü vor einigen Monaten.

Wir haben noch einige Erweiterungen zum Handelssystem geplant, die in den nächsten Tagen und Wochen online gehen werden… Aber jetzt wünsche ich allen zunächst einmal Frohe Weihnachten!

Dev-Blog Donnerstag 51/15

Dev-Blog Donnerstag 51/15

Von Entwicklern für Entwickler

[Horst (Slayer)]

Während unsere Spieler die erst letzte Woche aktivierten Weihnachtspiraten jagen, beschäftigen wir uns weiterhin mit UnitTests und dem Logging / Tracing bzw. der Anzeige von Fehlern.

Kurze Hintergrundinfo: wir zeichnen an allen möglichen Stellen im Spiel Zustände auf, die so nicht sein sollen. Wenn also eine Methode oder eine Datenbankabfrage ein unerwartetes Ergebnis liefert, wird das an unseren Log-Handler geschickt.

Je nach Art des Fehlers werden weitere Aktionen ausgelöst. So schicken wir uns zusätzlich ein Mail, wenn im CronJob (erledigt Hintergrundberechnungen wie z.B. Ressourcenproduktion) ein schwerer Fehler oder eine Exception passiert. Das ermöglicht uns, bei solchen zumeist fatalen Ereignissen so rasch als möglich zu reagieren.

Für manche Fehler schickten wir uns bisher eine Ingame Message. Fehler, die nicht ganz so fatal sind, aber die wir uns auf jeden Fall näher ansehen sollten. Im Bereich der UnitTests hat das allerdings gestört. Iwan hat ein sehr gutes Tool gefunden, welches wir nun einsetzen. Pimp my Log heißt das Teil. Ingame Fehler-Messages an unsere Team-Accounts sind damit Geschichte.

Aufgrund der aktuellen Aktivitäten im Bereich des Refactorings & Testings und der Vorbereitung neuer Features (bei mir steht die Flottenteilung an), ist der Kampftrainer mit Construct derzeit komplett in den Hintergrund geraten.

Die Spenden für die Sonneninsel laufen im Verhältnis zur Anzahl aktuell aktiver Spieler sehr gut, wir stehen nun bei 85€. Hier wurde mittlerweile innerhalb von 2 Wochen mehr gespendet, als für eXperinox für das gesamte Jahr. eXperinox hat also Spieler mit Herz – darauf sind wir direkt etwas stolz 🙂 .

[Iwan (shlainn)]

Die Woche ging schon mal schlecht los – Erkältung 🙁 Ansonsten stecke ich mitten im Aufbau des Handels und dem damit verbundenen Refactoring verschiedener Interna von eXperinox. Das produziert leider wenige „screenshotbare“ Ergebnisse…

Daneben habe ich endlich den Server, den ich vor einigen Wochen für interne Aufgaben von eXperinox eingerichtet habe, einer sinnvollen Nutzung zugeführt – nämlich den von Horst erwähnten Unit Tests. Das hat ein paar unrunde Stellen in den Tests aufgedeckt – die daraufhin behoben wurden.

Dev-Blog Donnerstag 50/15

Dev-Blog Donnerstag 50/15

Von Entwicklern für Entwickler

[Horst (Slayer)]

Um nicht Gefahr zu laufen, das mit den UnitTests wieder aufzuschieben, habe ich letzten Freitag gleich damit begonnen, alle alten UnitTests wieder zum Laufen zu bringen. Mit dabei einer, der seit dem Umbau des Message-Systems nicht angepasst wurde. Genau genommen ein No-Go, denn normalerweise sollte man vor dem Releasen eines solchen Umbaus zuerst die UnitTests wieder zum Laufen bringen. Aber genau das ist der Unterschied zwischen Theorie und Praxis! Theoretisch müsste das schon so sein, aber in der Praxis findet sich bei nicht ganz so beliebten Arbeiten sehr schnell ein Grund, es vorerst einmal aufzuschieben. Der Grund damals war die GameStage Expo 2014. Ja, 2014. Wie die Zeit vergeht 😉 .

Wie auch immer. Jedes Mal, wenn ich an UnitTests arbeite, bin ich erneut davon überzeugt, dass diese sehr viel Sinn machen. Man testet damit seinen Code und vor allem die Interfaces / public Methoden noch einmal und findet fast immer etwas, was man verbessern kann. Und auch den ein oder anderen Fehler, weil man sich noch einmal ganz intensiv mit der entsprechenden Funktionalität beschäftigt.

Und dann war es auch an der Zeit, das Blog etwas besser zu kategorisieren. Mittlerweile haben wir 152 (!) Blog-Beiträge veröffentlicht. Eine stolze Zahl und ein weiterer Beweis, für Durchhaltevermögen. Denn viele Blogs starten rasant durch und geben nach ein paar Beiträgen auf, weil dann noch immer nicht hunderte Besucher mit Begeisterung das bisher so vermisste Blog aufsuchen 😉 .

Rein funktional habe ich das Reparieren der Raumschiffe nun dahingehend abgeändert, dass es ab sofort auch Slots in den entsprechenden Fabriken belegt. Es fühlte sich immer etwas unrund an, dass man Raumschiffe quasi im Freien reppen (neudeutsch für reparieren) konnte. Auch vom Balancing ist es nicht schlecht, wenn damit allzu aggressive Zeitgenossen etwas eingebremst werden, weil das reparieren vieler beschädigter Raumschiffe nicht mehr so schnell geht.

XMAS Flotten im noXiversum
XMAS Flotten im noXiversum

Neben dem Aktivieren der X-MAS-Flotten (simple Änderung in einer DB-Tabelle) habe ich auch noch eine neue Piratenflotte integriert. Das geht aufgrund unseres relativ sauberen Codes in diesem Bereich recht einfach – samt individueller noX und DNA Belohnungen beim Abschuss.

[Iwan (shlainn)]

Zwischen Weihnachtsfeiern und anderen real-life Veranstaltungen ist derzeit wenig Zeit für eXperinox. Nichtsdestotrotz haben wir in einer äußerst produktiven Session weitere Details des Handelssystems, und des damit einhergehenden Refactorings unseres internen Handlings von Ressourcen festklopfen können.

Ressourcen sind ein zentraler Bestandteil von eXperinox und spielen an vielen  Stellen eine Rolle. Gebäude bauen, Raumschiffe konstruieren, Ressourcen sammeln und verarbeiten, Reparaturen und Recycling, Transport und demnächst auch Handel  bewegen auf die eine oder andere Art Ressourcen hin und her (zumindest aus der Perspektive des Programmierers). All diese Interaktionen objektorientiert abzubilden ist nicht ganz einfach, denn eine Klasse von Objekten soll immer nur für eine einzige Sache zuständig sein – die Faustregel lautet „Wenn du das Wort ‚und‘ brauchst um in einem Satz zu Beschreiben was die Klasse tut,  brauchst du zwei Klassen“. Ach, die Freuden von OOP (in PHP)… 😉

15. Testen ist alles

Testen ist alles

Nachdem wir im September 2009 unsere erste Flottenmission umgesetzt hatten, ging es mit der Entwicklung rasch vorwärts. Zum einen wurden immer mehr Gebäude „mit Leben gefüllt“ und es sind auch immer mehr Flottenmissionen entstanden.

Und so wurde eXperinox immer umfangreicher und das Testen neuer Funktionen ein immer wichtiger werdender Faktor während der Entwicklung.

15. Testen ist alles weiterlesen