In meinem Job automatisiere ich funktionale Oberflächentests mit Java. Die Testfälle führe ich mittels des TestNG-Frameworks und Selenium aus. Jeder Testfall ist mittels @Annotation mindestens einer Testgruppe zugeordnet. Die Testfälle werden parallel mit unterschiedlichen Anwendern ausgeführt, da ein Anwender sich zeitgleich nur ein mal am System anmelden kann.
Bei der Ausführung eines parallelisierten Smoketest-Sets bin ich dann jedoch ins Stolpern geraten. Ziel ist es Testfälle auszuführen, welcher der Gruppe Group User A und der Gruppe Smoketest zugeordnet sind. Parallel dazu in einem anderen Thread sollen die Testfälle ausgeführt werden, welche der Gruppe Group User B und der Gruppe Smoketest zugeordnet sind. Leider lässt sich das nicht so einfach in der suite.xml definieren, sondern ein eigener Listener muss geschrieben werden.
Bereits vor eingier Zeit habe ich Vagrant in einem extra Beitrag vorgestellt und kurz erläutert, welche Vorteile Vagrant in Entwicklungsteams mit sich bringen kann. Seither nutze ich Vagrant um schnell und einfach immer die gleichen Bedingungen und Voraussetzungen für meine Entwicklungen zu schaffen. Es gibt bereits viele Vorlagen von Entwicklern für Vagrantfiles die für spezielle Zwecke alle Vorbedingungen in der VM automatisch schaffen. Ich selbst jedoch nutze die File, beziehungsweise Vaprobash, von Chris Fidao.
Gestern war es dann endlich mal wieder so weit. Seit April habe ich mich mit meinem Blog gar nicht mehr beschäftigt, doch gestern Abend packte mich dann wieder der Ehrgeiz, der ganzen Sache wieder mehr Aufmerksamkeit zu widmen.
Zuerst wollte ich natürlich mein zu Grunde liegendes Contao 3.1 auf die aktuelle Version 3.3.5 aktualisieren. Leider sind mir unglücklicherweise meine damals routinierten Schritte für ein reibungsloses Update entfallen, weshalb ich den Prozess nun hier kurz festhalte.
Gestern führte ich das Update auf Contao 3.3.5 durch. Doch leider verleif dieses nicht ganz problemlos. Nach meinem Update erhielt ich nach dem Aufruf der install.php folgende Fehlermeldung:
Fatal error: Class 'Contao\BaseTemplate' not found in .../system/modules/core/library/Contao/Template.php on line 34
Wie schon vorher mal erwähnt, arbeite ich in letzter Zeit oft mit dem AngularJS Framework. Da ich ein Laravel-Fan bin, kommt es beim Templating dann nur leider zu einem kleinem Problem. Sowohl die Blade Engine von Laravel, als auch die Engine von AngularJS setzen auf „Double Curly Brackets“, also die doppelt geschwungenen Klammern. Das führt natürlich bei der Interpretation letztendlich zu ein paar unangenehmen Fehlern.
In letzter Zeit probiere ich viele Sachen mit AngularJS. Während ich mich in den Basics sicher fühle, stoße ich ab und an noch auf so einige Verständnisprobleme. Zum Beispiel: Warum besteht ein Unterschied zwischen einer object-dotierten und Array-dotierten Liste von Objekten? Wahrscheinlich ist das eher ein JS-Bug/Feature und genau so gewollt, jedoch hat mich AngularJS damit verwirt, dass ng-repeat auf beide Listen problemlos anwendbar ist. Das Filtern und Sortieren hingegen nicht. Doch noch ein mal zum Ursprung dieses Problems.
Composer ist die Abhängigkeitsverwaltung für PHP schlecht hin. Wer aktuell große PHP Projekte mit zahlreichen Abhängigkeiten zu Frameworks und anderen Bibliotheken umsetzt, wird vermutlich auf Composer als Dependency Manager und Autoloader setzen.
Die wohl meist verwendete Autoload-Variante in Composer ist aktuell PSR-0. Dabei werden Klassen auf Basis der Ordnerstruktur, beziehungsweise der Dateipfad-Struktur geladen und automatisch in den entsprechenden Namespaces bereitgestellt. Seit gestern bietet Composer nun auch die Möglichkeit den bereits vorgestellten, aber noch nicht akzeptierten, PSR-4-Standard zu nutzen. Was die Unterschiede sind und wie die Verzeichnisstruktur nun auszusehen hat, wenn man PSR-4-Autoloading nutzen möchte, will ich kurz aufzeigen.
