Wie testet ihr eure Plugins..

    ... bevor sie veröffentlicht werden?



    Aus gegebenen Anlass wollte ich mal die Frage in den Raum werfen, unter welchen Bedingungen ihr (nicht nur Tom & Cr@@gle) eure Plugins eigentlich testet?


    Mir sind heute Nacht bei zwei Plugins für das WS3.0 ganz gravierende Fehler aufgefallen die mich zu dem Schluss kommen lassen, das einige Entwickler ihre Plugins nicht großartig unter Realbedingungen testen. Ohne jetzt direkt Namen etc. nennen zu wollen, macht mich dieses ebenso Wütend wie meiner Freundin, die als Geldgeberin die Plugins gekauft hat. Einige Entwickler, von denen ich früher einmal angenommen hatte das sie nicht sorgfältig arbeiten würden haben mich eines besseren belehren können.


    Das Standard-Stil der WoltLab Suite 3.0 ist ja bekanntermaßen sehr Mager im Aussehen. Das mag nicht jeder Gut finden (darunter zähle ich auch), aber gewisse Grundeigenschaften bei Plugins müssen ihre charakterlichen Züge trotz des Spar-Designs aufweisen. Beispielsweise Buttons an entsprechenden Stellen vorkommen oder Menüpunkte entsprechend ihrer Funktion nicht vom allg. üblichen Standort und Funktionsumfang abweichen. Sprich - das tun was man erwartet. Gerade wenn man z.B. ein Plugin aus älteren WoltLab-Versionen bereits kennt. Einen kompletten Stilbruch gilt es doch m.E. zu vermeiden.


    Testet ihr eure Plugins nur im Standard-Stil und bei einem von Plugins von Drittenentwickler freien WoltLab Suite?


    Aus meiner eigenen Zeit, als ich noch das eine oder andere Mini-Plugin produziert habe, habe ich die Plugins in zwei unterschiedlichen Foren getestet. Das eine Forum mit dem Standard-Stil und den Grund-Funktionen (ohne andere Plugins von anderen) und im zweiten Forum habe ich immer 3 ganz verschiedene Stile und etliche Plugins installiert, so wie es möglicher Weise auch die Anwender nutzen würden.

    • Teambeitrag

    Ich teste und erstelle meine Plugins tatsächlich nur in einer „leeren“ Testinstallation ohne weitere Plugins und Stile. Häufig teste ich Änderungen auch nicht. Wenn zum Beispiel jemand einen Fehler meldet, dann behebe ich den und erstelle ein neues Paket. Da kann es natürlich immer zu Seiteneffekten oder Packfehlern kommen. Mir ist das dann doch zu viel Aufwand jede kleine Änderung durchzutesten die theoretisch funktionieren sollte.


    Bei Stilen ist das anders. Bevor ich die Pakete in den Shop lade, teste ich ob sie sich fehlerfrei installieren lassen und ob die Stile, sowohl als Gast als auch als Mitglied, funktionieren.


    Erweiterungen von Drittanwendern lasse ich aber grundsätzlich immer außen vor.

    Deine Anfrage wurde nicht beantwortet? Dann bitte einfach noch mal kurz im Thema nachfragen.


    Mein Blog: TwentyMag <- Lesen, Teilen, Liken, Kommentieren, Abonnieren. Ihr wisst bescheid, was labere ich hier groß rum :eyes:

    Gefällt mir 2
    Zitat von Tom

    Erweiterungen von Drittanwendern lasse ich aber grundsätzlich immer außen vor.

    da würdest ja auch gar nicht mehr aus der Arbeit rauskommen, wenn du echt alle Begebenheiten testen wollen würdest :D


    Und du hast ja für die Stile - sogar für jeden Stil einzeln, eigene Supportbereiche und bist der letzte, der nicht helfen würde, wenns bei einem Plugin iwie Stilprobleme gäbe...


    Alle Situationen kann man echt net testen - dafür gibts ja dann die Supportbereiche.... allerdings unverschämt wäre, wenn man Kaufplugins holt und dann keine Hilfe fände... oder (wie mirs mal beim wem passierte )- man noch freche Antworten bekäme - es würde funktionieren, obwohl zig andere Leute das Plugin mittlerweile auch für Schrott hielten, da es immer noch nicht so wirklich tut, was es soll - habs mittlerweile deinstalliert und hak die fünf Euro als Lehrgeld ab und kauf bei dem einfach nix mehr xD - gibt genug andere Bastler und dann brauch ich halt Plugin xy doch nicht und verzichte lieber auf jene Funktion

    Zitat von Perikles

    Testet ihr eure Plugins nur im Standard-Stil und bei einem von Plugins von Drittenentwickler freien WoltLab Suite?

    Das ist irgendwie eine seltsame Frage. Die Antwort ist natürlich ja.
    Zum einen ist es unmöglich, alle möglichen Kombinationen von Stilen und Erweiterungen zu testen. Und zum anderen sollte das ausreichen, wenn man sich an Stil- / API-Vorgaben von WL und deren 'Best Practices' hält.


    Probleme mit Stilen gibt es in der Regel nur, wenn Stile fehlerhaft sind. Und Probleme mit anderen Plugins (im Betrieb) gibt es nur, wenn diese nicht systemkonform bzw. unkooperativ geschrieben sind; Klassiker dürfte ein verbogene EventListener sein, der andere Plugins alt aussehen lässt, die diesen EL auch nutzen.

    Zitat von UdoZ

    Und Probleme mit anderen Plugins (im Betrieb) gibt es nur, wenn diese nicht systemkonform bzw. unkooperativ geschrieben sind;

    Zitat von UdoZ

    wenn man sich an Stil- / API-Vorgaben von WL und deren 'Best Practices' hält.

    Zitat von Tom

    Erweiterungen von Drittanwendern lasse ich aber grundsätzlich immer außen vor.


    Auch wenn man sich selbst an alle Standards und Vorgaben hält und noch so penibel nach Fehlern aus schau hält sind Fehler nicht ausgeschlossen. Mir sind in der langen Zeit einige Plugins untergekommen die sich zwar an allen Vorgaben und Standards hielten, jedoch die merkwürdigsten Effekte (Fehler) hervor gerufen haben.


    Der Klassiker dabei ist das Doppelte-Lottchen. Das sind Plugins die ein und die gleiche Funktion besitzen und z.T. auch den selben Code. Der einziger Unterschied besteht lediglich darin, das die Plugins von ganz unterschiedlichen Entwicklern und ohne dem Wissen voneinander (also das keiner wusste das der andere daran arbeitete) hergestellt und vertrieben wurden.


    Als aktuelle Beispiele wären hier die Plugins: ACP User Menü Link, Benutzermenü: Link zum ACP und seit Kurzem habe ich auch dieses Plugin Userpanel Mod gefunden. Ich möchte keines der Plugins jetzt bewerten, denn alle Drei haben ihre Daseinsberechtigung. Was mich jedoch verwundert ist, das keiner die anderen Pakete ausschließt via


    <excludedpackages>, so wie es eigentlich üblich ist.


    Natürlich, und das würde ich nie abstreiten, ist es der Aufwand Plugins in einer relativ natürlichen Umgebung zu testen höher, schadet aber auch nicht. Die meisten Entwickler werden erst aktiv, wenn das Kind in dem Brunnen liegt. Worum es mir geht ist es, Entwickler fern ab ihres Computers für die Arbeiten der Kollegen zu sensibilisieren. Einfach mal zu schauen was der Nachbar gerade an Wäsche aufgehängt hat und zu schauen ob sich da nichts mit den eigenen Arbeiten beißt.


    Einige andere Dinge gibt es auch, wo ich den Eindruck habe, das dass Plugin ungesehen oder ohne nennenswerte Test mit wenigstens einem anderen Stil als dem Standard auf dem Markt geworfen wurde. Das ein Plugin im Standard Stil einen sauberen und guten Eindruck macht, aber sich im Stil XYZ plötzlich komplett zum Horror entwickelt liegt schlicht und einfach entweder an der Gleichgültigkeit oder aber am Unvermögen des jeweiligen Plugin-Entwickler. Man kann kein Plugin mit den vielen 100 Stilen testen, besonders wenn die Stile kostenpflichtig sind. Man kann sich aber einen kleine Auswahl an Stilen dennoch dazu holen um eine gewisse Sicherheit zu haben.


    Am Ende sind es die Anwender die sich über plötzlich auftauchende Fehler und Problemen aufregen.

    Zitat von Perikles

    Auch wenn man sich selbst an alle Standards und Vorgaben hält und noch so penibel nach Fehlern aus schau hält sind Fehler nicht ausgeschlossen.

    Korrekt. Es gibt keine fehlerfreien Plugins, wenn diese einen gewissen Umfang haben, und man kann solche Plugins naturgemäß nicht 100%-ig durchtesten und alle Fehler beseitigen. Deswegen ist es nicht ausgeschlossen, dass trotz tagelanger eigener Tests und öffentlicher Beta-Tests auch banale Fehler es in den Release schaffen. Wenn dann der Support stimmt, ist doch alles in Ordnung.



    Zitat von Perikles

    Der Klassiker dabei ist das Doppelte-Lottchen.

    Zitat von Perikles

    Was mich jedoch verwundert ist, das keiner die anderen Pakete ausschließt via


    <excludedpackages>, so wie es eigentlich üblich ist.

    Es gibt nach meinem Verständnis nur genau einen Grund, andere Pakete auszuschließen: technische Unverträglichkeit.
    Identische Funktion ist kein valider Ausschlussgrund, denn 1. belebt Konkurrenz das Geschäft und 2. sollte man immer von mündigen Nutzern ausgehen, die selbst entscheiden können, was sie installieren.


    Zu der Stil-Geschichte: agree to disagree ;)



    Zitat von Perikles

    Am Ende sind es die Anwender die sich über plötzlich auftauchende Fehler und Problemen aufregen.

    Ja, in der Regel zurecht. Aber da Fehler unvermeidbar sind, müssen beide Seiten damit leben und ganz einfach nur vernünftig damit umgehen.

    Zitat von Perikles

    liegt schlicht und einfach entweder an der Gleichgültigkeit oder aber am Unvermögen des jeweiligen Plugin-Entwickler.

    Das heißt im Umkehrschluss aber vollkommene Narrenfreiheit für alle Design-Ersteller. Denn so wie du es schreibst, sind für dich immer die Plugin-Entwickler schuld. Ein starkes Stück und aus meiner Sicht, der ich sowohl Plugins als auch Designs anbiete, ein vollkommener Trugschluss.


    Es gibt immer Konstellationen, die schwierig sind, wenn es zum Zusammenspiel eines alternativen Designs mit einem Plugin kommt. Ob ich ein Plugin nun mit 5 oder mit 50 Stilen teste, am Ende ist es dann der 51. Stil, der ein Problem mit diesem Plugin hat. Liegt es dann immer noch am Plugin? Oder liegt es nur dann am Plugin, wenn es ein populäres Design ist? Nein, eine pauschale Aussage ist hier, so wie du es gemacht hast, meiner Meinung nach überhaupt nicht möglich.


    Viel mehr ist das immer eine Einzelfallentscheidung, ob an dieser Stelle das Design oder das Plugin verbessert werden muss. Wenn sich das Plugin an die Standards hält, ist es meiner Meinung nach am Designer, das Problem zu beheben. Ist das nicht der Fall, muss erst der Plugin-Ersteller aktiv werden.

    • Teambeitrag

    Das größte Problem bei der Darstellung ist das nicht der gesamte Code frei verfügbar ist sondern nur der der mit dem Core ausgeliefert wird. Als Beispiel kann man die Filebase, den Marktplatz und die POI-App anführen. Alle Apps verwenden in der Übersicht die selbe Darstellung, da der Code der Filebase aber nicht frei verfügbar ist, baut jeder die Darstellung nach. Das mag zwar im Standardstil noch passen, aber ich müsste jetzt im Prinzip drei mal das selbe Element in einem Stil anpassen. Wenn mich nicht alles täuscht verwendet die Webdisc auch diese „Card“, das wäre dann schon vier mal unterschiedlicher Code für das selbe Element. Und da gibt es noch zich andere Beispiele für nachgebaute Elemente.



    Das ist noch irgendwo ein konzeptioneller Schachpunkt im Framework. Man stellt zwar eine Basis bereit, aber dann doch nicht so wirklich.

    Zitat von Tom

    Als Beispiel kann man die Filebase, den Marktplatz und die POI-App anführen. Alle Apps verwenden in der Übersicht die selbe Darstellung, da der Code der Filebase aber nicht frei verfügbar ist, baut jeder die Darstellung nach.

    Ja, das ist tatsächlich so. Ist ist aber, Achtung Unwort, alternativlos, wenn man die Anwendung optisch zum Rest passend gestalten will. Mit Bordmittel (des WSC) ist es einfach nicht möglich, weswegen das ein potenzielles Problem mit jeder Drittanbieter-Anwendung ist.


    Zitat von Tom

    Das ist noch irgendwo ein konzeptioneller Schachpunkt im Framework. Man stellt zwar eine Basis bereit, aber dann doch nicht so wirklich.

    ACK.