Core-Entwicklung zu schnell?
-
... und dann sind wir wieder beim Thema "Kommunikation". Deshalb versuche ich all die Punkte hier zu klären; später sollten die in die Doku - auch wenn die dann niemand liest, kann ich zumindest jedem sagen: "RTFM"
@thebam sagte in Core-Entwicklung zu schnell?:
Ich finde es ja zum einen gut, wenn ein Projekt lebt und sich was tut. Aber mir geht das ganze auch etwas schnell, wenn ich auf dieses Jahr zurück schaue wurde Weblade eingeführt,
Weblate ist optional für Adapter die viele Übersetzungen haben und für jene, die eine grosse Verbreitung haben. Der Einstieg steht aktuell hier: https://github.com/ioBrokerTranslator/doc/#purpose (wird aber sicherlich in die Entwickler Doku eingebaut). Es gibt absolut keinen Zwang, Weblate einzusetzen.
Sentry (Wo ich immer noch nicht weiß wie es funktioniert)
Sentry ist ebenfalls optional und vor allem für Adapter, die sehr aktiv entwickelt werden, da man so sehr schnell auf Fehler reagieren kann, noch bevor Issues auf GitHub erstellt werden (wenn denn überhaupt jemals). Die Dokumentation dazu ist aktuell hier: https://github.com/ioBroker/plugin-sentry#readme
React,
Ist ebenfalls optional und nur für Adapter gedacht, die sehr komplexe UIs haben. Die Dokumentation dazu ist quasi inexistent; das muss nachgeholt werden!
JSONCostum.
Custom JSON ist sehr interessant für Adapter, die ein ganz einfaches Admin UI benötigen. Die Dokumentation dazu ist gut versteckt hier zu finden: https://github.com/ioBroker/ioBroker.admin/blob/a19915fdb2daa9c96ad189d16d824be06962123b/src-rx/src/components/JsonConfigComponent/SCHEMA.md Auch hier besteht ohne Zweifel Bedarf, das besser zu dokumentieren.
Das sind schon mal sehr viele große Brocken wo man sich als Hobby Entwickler erst mal rein arbeiten muss um überhaupt damit umgehen zu können und wenn ich dann höre das evtl. die Alte HTML Version abgeschafft/ nicht mehr unterstützt werden soll ist das schade (ich hoffe das die noch weiter mit im Admin bleiben darf).
Davon, dass HTML GUI abgeschafft werden soll, habe ich noch nie gehört, aber vielleicht kann mich jemand anderes korrigieren.
Weiterhin ist glaube im Oktober der Controller 3.3 rausgekommen seitdem kommen wöchentlich neue Versionen (gefühlt) wenn ich dann aber höre das im Januar schon Version 4 rauskommen soll bleibe ich einfach auf der Stecke.
Was sind die für Entwickler relevanten Änderungen zwischen 3.3 und 4? Kaum welche: https://github.com/ioBroker/ioBroker.js-controller/blob/master/CHANGELOG.md#400-2021-xx-xx-release-i-cut-off-13122021-1100 (siehe "Developer relevant" Überschriften)
Jeder Mensch hat 24Std. am Tag zu Verfügung und ich würde mir wünschen das man eine Version raus bringt die rein theoretisch die nächsten 2 Jahre "Aktuell/Stabil" sein sollte und dann Maximal im Jahres Rhythmus eine neue Version bringt. Sprich wenn man eine Version fertig hat nicht direkt mit einer neuen beginnt, sondern sich um andere Dinge kümmert wie. Adapter anfragen Issues oder aber auch Pull Request beim Reposetory man muss halt einfach nur seine Zeit anders einteilen.
Kein einziger (Core) Entwickler macht neue Features aus Freude, ein neues Feature einbauen zu können. Jedes Feature hat einen Grund und hat entweder mit Neuerungen in den Abhängigkeiten (NodeJS ist leider auch nicht 2 Jahre "stable") oder mit Anforderungen von Adaptern / Usern zu tun.
Trotz allem: ein Adapter, der zwei Jahre alt ist, funktioniert auch heute noch mit ioBroker. Eventuell gibt es einige Fehlermeldungen und neuere Features (z.B. Device Detection) funktionieren nicht, aber "breaking" ist da IMHO nichts.
Das Relase Script ist eine tolle Sache mein Problem ist nur immer, wenn ich es nutzen will habe ich neue Probleme da ist es nicht jeden Tag nutze sondern ehr so im 3 Monates Rhythmus.
Alternative: den Adapter über "Releases" auf https://www.iobroker.dev freigeben.
Daher würde ich mir wünschen das ihr die Hobby/self lern Programmierer nicht abhängt weil es einfach alles zu schnell geht.
Eine bessere Kommunikation wird dir zu verstehen geben, dass sich gar nicht so viel ändert. Es scheint nur so viel, weil es immer wieder (immer etwas anders) hoch kommt.
Es soll auch keine Kritik sein sondern einfach von der Seele reden. Denn ich finde es super was hier Leute auf die Beine gestellt haben dafür auch ein dickes. Lob ebenso wie für die iobroker.dev seite die ich sehr gerne nutze.
Im Namen von allen, die du ansprichst: Danke!
Und zum Schluss (auch wenn das wohl niemand mehr liest): ich hoffe, jeder liest dann die neue Entwickler Dokumentation und beklagt sich nicht einerseits darüber, dass man als Entwickler "abgehängt" wird und sagt andererseits, niemand lese die Doku. Das ist ein Widerspruch!
Edit: die erwähnten Themen habe ich hier als Issue zusammengefasst: https://github.com/ioBroker/dev-docs/issues/4
open Missing doc topics #4
-
@arteck said in Core-Entwicklung zu schnell?:
ich habe mir jetzt die 3 Seiten durchgelesen ... und erlebe ein dejavu.. alle Jahre wieder...
Doku is kacke... -> ja und wer liest die KEINER... deshalb auch die grosse Motivation seitens der Adapter Entwickler /Core Entwickler
Dem möchte ich vehement widersprechen! Wenn die Doku denn vorhanden wäre, würde ich darin lesen!
Wenn die Entwickler aber keine Motivation haben, eine Doku zu erstellen, KANN KEINER diese lesen! -
@andreas-5 sagte in Core-Entwicklung zu schnell?:
würde ich darin lesen!
ja ja immer diese.. ich ich ich
....
nein im ernst.. das Problem ist 100 Leute wollen 1 machts.. der Rest fragt dumm rum..es ist deprimierend wenn man jedesmal es erwähnen muss.. und dann kommt..hab schon .. hab ein Video gefunden ..von anno 1890 .. und dann kommt es geht nicht
-
@arteck
Dann müssen wir ein Video drehen wie du aus dem Doku-Manuskript vorliest. -
Puhh, der Thread ist jetzt echt mächtig lang geworden, ABER ich bin überzeugt, dass ich nicht der einzige bin, der jedes Wort mitgelesen hat.
Ich hätte noch eine letzte Anregung an alle beteiligten. Am besten in einem neuen Thread.
Bitte überlegt Euch mal, ob ihr neue Entwickler wollt bzw. wo die herkommen könnten. Professionelle Entwickler gibt es viele, nur sind die meist schon irgendwo gebunden. Ich beobachte, dass es sehr viele Leute im Bereich Javascript Adapter gibt, die sehr umfangreiche Scripte erstellen. Teilweise enthalten die viel mehr Code als manche Adapter. Und viele Projekte aus dem Java-Script Adapter sind auch schon von dort in Adapter gewandelt worden. Ich denke, dass es dort noch mehr neue Entwickler geben würde, wenn sie den Einstieg finden würden.
Das nur noch als Anregung bzw. Gedanke. Eventuell gibt es das Thema ja auch schon bei Euch auf der Agenda.
Ich wünsche Euch allen einen guten Rutsch ins Neue Jahr 2022.
Eisbaeeer -
@thebam sagte in Core-Entwicklung zu schnell?:
Ich finde es ja zum einen gut, wenn ein Projekt lebt und sich was tut. Aber mir geht das ganze auch etwas schnell, wenn ich auf dieses Jahr zurück schaue wurde Weblade eingeführt, Sentry (Wo ich immer noch nicht weiß wie es funktioniert) React, JSONCostum. Das sind schon mal sehr viele große Brocken wo man sich als Hobby Entwickler erst mal rein arbeiten muss um überhaupt damit umgehen zu können und wenn ich dann höre das evtl. die Alte HTML Version abgeschafft/ nicht mehr unterstützt werden soll ist das schade (ich hoffe das die noch weiter mit im Admin bleiben darf).
Weiterhin ist glaube im Oktober der Controller 3.3 rausgekommen seitdem kommen wöchentlich neue Versionen (gefühlt) wenn ich dann aber höre das im Januar schon Version 4 rauskommen soll bleibe ich einfach auf der Stecke. Da ich nur so daran arbeiten kann wie ich Zeit habe und derzeit auch noch Privat einiges anderes zu tun habe bin ich in den Letzen 3 Monaten kaum dazu gekommen an einem Adapter zu arbeiten.Wie bereits dargestellt ist alles optional - ausser das Custom-JSONConfig wurde quasi zur Pflicht weil es in Admin5 nicht mehr möglich war hier das alte zu supporten. Das betraf aber eine Handvoll Adapter.
Was den Controller angeht hast Du glaube nur ein "gefühl":
- js.controller 3.3: Beta/Latest: 29. Apr. 2021, Stable: 4. Aug. 2021
Der Controller ist an sich mit Latest Release Feature-Complete und ab dann gibt es nur fixes bis Stable. Sobald der Adapter im Stable ist gibt es nur noch "emergency Fixes".
Ja die Zeit zwischen 3.2 und 3.3 war recht kurz, aber das wir nicht nochmal vorkommen
-
@thebam sagte in Core-Entwicklung zu schnell?:
die Alte HTML Version abgeschafft/ nicht mehr unterstützt werden soll ist das schade
Nur um nochmal deutlich zu werden, da es bei @apollon77 nicht ultra klar rauskam:
- HTML Config-Seite bzw. Tab ist definitiv nicht deprecated und wird es aller Voraussicht auch nie. Der Rest sind alles optionale Alternativen für einfache (JSON Config) oder komplexere (React) UIs.
- HTML Custom (das ist dort wo man z.B. History für einzelne Datenpunkte) allerdings schon
Das Relase Script ist eine tolle Sache mein Problem ist nur immer, wenn ich es nutzen will habe ich neue Probleme
Sorry wenn ich so direkt werde... wo sind die Issues dazu? Ich kann nur aus meiner eigenen Erfahrung sagen - bevor ich das vor kurzem neu geschrieben habe um es flexibler und modular zu machen, hatte ich es bestimmt 1 Jahr nicht groß angefasst und nahezu täglich problemlos genutzt.
-
@alcalzone sagte in Core-Entwicklung zu schnell?:
Sorry wenn ich so direkt werde... wo sind die Issues dazu? Ich kann nur aus meiner eigenen Erfahrung sagen - bevor ich das vor kurzem neu geschrieben habe um es flexibler und modular zu machen, hatte ich es bestimmt 1 Jahr nicht groß angefasst und nahezu täglich problemlos genutzt.
Wenn ich die fehler kennen würde dann könnte ich auch ein Issue machen das problem ist das ich den fehler noch nicht mal wiedergeben kann. Einmal hattest du mir mal geholfen musste dann aber alle node_modules Löschen und neu installieren dann ging es.
-
@thebam sagte in Core-Entwicklung zu schnell?:
das problem ist das ich den fehler noch nicht mal wiedergeben kann
Aber du erkennst dass es einen Fehler gibt. Damit kann man doch starten.
Vermutlich hast du npm 7, da hab ich erst vor sehr kurzem festgestellt, dass es Probleme gibt, weil es erst da gemeldet wurde. Da war auch nicht direkt klar, was das Problem ist. -
Hi nochmal von mir,
ich bedanke mich für die Diskussion und alle Beiträge. Da mich allerdings das Feedback erreicht hat das sich wohl einige Entwickler missverstanden gefühlt haben bzw. das Gefühl hatten das Ihre Themen abgewürgt wurden kann ich nur gern jeden aufrufen mich direkt (PN Forum, Discord, Telegram, Email, However) anzuschreiben wenn es noch Gesprächsbedarf gibt.
Ich kann generell natürlich nachvollziehen wie es sich für Entwickler anfühlt, wenn so viel auf einmal in kurzer Zeit passiert: Neue Tools, neue Möglichkeiten, Travis ist Tod - es leben GitHub Actions und auch noch ein js-controller der die "nie geahndeten Sünden" der Vergangenheit bzw. vllt auch die damalige Unwissenheit mit einer schwach typisierten Programmiersprache wie JavaScript offenlegt; Zusammen mit der Aufforderung das jetzt "mal eben schnell" für die Adapter die doch seit Jahren gut laufen ändern zu müssen. Hinzu kommt das sich noch die Haupt-Kommunikationswege weg vom Forum mehr hin zu GitHub, Discord und Telegram ändern. Da kann man sich schon abgehängt fühlen und es fühlt sich alles "schnell" an.
Bin ehrlich - ging auch mir so an einigen Stellen und ja es kostet Zeit sich da reinzufinden ... danach bringt es aber Zeit.Bei genauerem hin sehen sind aber die js-controller Deprecations die relevanten und "nötigen" Themen - der Rest ist alles cool, aber optional. Natürlich ist es dennoch Aufwand sich ggf nach längerer ioBroker-Development-Abstinenz oder mit knapper Zeit wieder in das Thema reinzuarbeiten. Hier ist es aber so wie auch früher: Die Dev-Community ist bei Fragen da und hilft so gut Sie kann - inzwischen sogar meistens aktiver und schneller als noch vor ein paar Jahren! Nutzt diese Möglichkeiten und ich bin sicher das wir alles - auch mit einer noch nicht vorhandenen guten Doku (, die in Arbeit ist) - gemeinsam hinbekommen.
Durch das eine Thema müssen wir jetzt leider durch. Ich kann natürlich keine Garantie geben das so etwas nicht nochmal passiert (dann würde ich mich unglaubwürdig machen), wir versuchen aber Rückwärtskompatibel zu bleiben so gut es uns möglich ist.Wenn jemand absehbar unsicher ist ob er den Adapter künftig weiter betreuen kann/möchte, dann ist es eine Idee diesen zu den Community-Adaptern zu übertragen. Der Entwickler kann es auch dort weiter pflegen so lange er will/kann, es macht aber - richtig übertragen - für die Zukunft einfacher falls die Zeit doch einmal nicht mehr da sein sollte.
Kommunikationstechnisch denke ich das kurz/mittelfristig folgendes machbar ist:
- Dev-Meetings werden versuchen frühzeitig zu informieren. Wer Zeit hat schaut vorbei, ansonsten gibt es (grobe) Protokolle und jeder mit Fragen ist eingeladen nach mehr zu fragen. Dazu kann man im Forum die Gruppe "https://forum.iobroker.net/category/119/entwickler-meetings" abonnieren und bekommt E-Mails
- Für Controller-Tests wird es weiterhin Testing Threads geben die im Forum oben angepinnt sein werden. Controller Changelog ist im GitHub
- Wir werden auch bei neuen Controller Versionen zum Alpha/Beta Test regelmäßig Massen PRs anzulegen in alle Adapter Repos; ebenso zu neuen Node.js Versionen. Das sollte ebenso eine E-Mail geben als "Push-Trigger". Wenn es für E-Mail Filter hilft können wir zB ein "[iobroker Official]" am Anfang des issue Namens schreiben das man E-Mail Filter bauen kann.
- Unter https://iobroker.dev sind schon jetzt wichtige Dev-Links zusammengefasst und es soll noch ein Changelog (mal mindestens für die Doku) hinzukommen, wenn es soweit ist. Das ist auch eine gute Anlaufstelle.
- Bei Fragen gibt es Discord, Telegram (Dev-Gruppe zwischen beiden Systemen gesynct) und das Forum; ggf (vor allem im Forum) bei Fragen bitte sinnvoll Devs "taggen"
Mit den oben genannten Varianten würde ich gern auf eine (bereits mehrfach vorgeschlagene) Mailingliste verzichten wollen weil auch diese wieder gemanaged werden muß und Datenschutzrechtliche Themen hat.
Das ist das was ich aktuell bieten kann und auch als "möglich sicherzustellen" sehe ... Wenn jemand Ideen hat was noch sinnvoll mit sinnvollem Aufwand machbar ist ... bitte vorschlagen.Ingo
-
@apollon77 wo gibt es denn kurz Protokolle zu den Dev-Treffen? Ich nehme dort nie teil weil ich kein Entwickler bin aber ich finde einige Themen schon für alle relevant und deshalb würden mich dort die Ergebnisse interessieren wie dort entschieden wurde...
P. S. Die Entwicklung vom js-controller hat schon ggü den ersten js-controller Versionen deutlich fahrt aufgenommen. Für mich als Nicht-Entwickler meist nicht relevant, bis auf die letzen Versionen, die doch viel Zeit gekostet haben durch die "Zwangsumstellung" auf userdata und die zugemüllten Log-Dateien.
Im Nachhinein bin ich froh über die Umstellung, da ich in diesem Zuge mal wieder aufgeräumt und neu strukturiert habe.
Man merkt schon, dass eine Menge Arbeit in der Entwickklung vom js-controller steckt, die Du und die anderen dort investieren, deshalb mein großer Dank. Ohne ioBroker wäre meine Automation nicht mehr vorstellbar. -
@cash sagte in Core-Entwicklung zu schnell?:
wo gibt es denn kurz Protokolle zu den Dev-Treffen?
-
@cash sagte in Core-Entwicklung zu schnell?:
durch die "Zwangsumstellung" auf userdata
Das war aber Admin5 und nicht der Controller ;-)) (nur so der vollständigkeit halber)
-
@sigi234 ich kann ja blind sein aber ich finde dort kein Protokoll. Z. B. Dezembertreffen dort gab es ein Thema: Roles und typeDetector - "Welche neuen Rollen und ggf Gerätetypen haben wir eingeführt?"
Aber im dem Thread steht nicht was es nun gab oder nicht...
Oder der User e.s. fragt ob ein Thema angesprochen wurde. Antwort: "Ja. Lösung ist angedacht"
Unter Kurz-Protokoll verstehe ich etwas anderes...
-
@cash sagte in Core-Entwicklung zu schnell?:
Aber im dem Thread steht nicht was es nun gab oder nicht...
Letzte neue Typen gab es im Juni oder Juli ... wir haben das aber als eines der "immer auf der Agenda Themen". Von daher: Ja hätte ein "nichts neues" Klarheit gebracht ... @ldittmar
Oder der User e.s. fragt ob ein Thema angesprochen wurde. Antwort: "Ja. Lösung ist angedacht"
Wenn etwas "Zu kurz" ist -wie oben geschrieben - einfach im Thread Fragen und wir ergänzen das fehlende.
-
@cash sagte in Core-Entwicklung zu schnell?:
@sigi234 ich kann ja blind sein aber ich finde dort kein Protokoll. Z. B. Dezembertreffen dort gab es ein Thema: Roles und typeDetector - "Welche neuen Rollen und ggf Gerätetypen haben wir eingeführt?"
Aber im dem Thread steht nicht was es nun gab oder nicht...@ldittmar sagte in Meeting für ioBroker Core/Dev/Admin 15.12.21 20:30:
Alles was im Meeting besprochen wurde, wird hier unterhalb der Themen, stichpunktweise dokumentiert.
-
Dann geb ich auch mal noch meine Sichtweise dazu.
Ich fand „Entwicklung geht zu schnell“ für mich sehr treffend.
Es geht mir weniger um den js-controller und ggf. die deprecations aus der neuen Version, die sind zwar auch nerven, aber sehe eher das ganze drumherum was sich mal schnell ändert.Zum einen gibt es die Änderungen die außerhalb von ioBroker stattfinden:
- nodejs,
- 3rd-party API,
- die Geräte selbst (neue Funktionen, neue Gerätespektrum,…)
- … usw.
Teilweise gibt es nicht einmal eine offizielle Doku um etwas aufzubauen und man weiß auch nicht so recht was man da an dependencies einbindet.
Zum anderen sind es die Dinge in ioBroker selbst:
- Umstellung auf compact mode,
- template/create adapter (mit den best practices), was man dann auch nachziehen möchte
- neue Funktionsaufrufe (auch teilweise als Ersatz was man vorher im Adapter hatte)
- admin Umstellungen
- neue Parameter in io-package
- … usw
- und auch die richtige Definition der Objekte
(wobei das eher ein Adapterfehler aus der Vergangenheit ist)
Für mich ist es ein Hobby und hauptberuflich bin ich kein Entwickler, bin also nicht mit allen Tricks und best practices in JS bewandert. Aber man lernt dazu. Also ist es Spaß an der Freude, das etwas läuft und auch anderen dienlich ist.
Die neuen Tools und auch Testautomatisierung kann ich nur unterstützen. Ich bin ein großer Fan von automatisierten Tests und Konsistenzprüfungen. Da hätte ich den Wunsch, daß sich hier bei den Integrationstests noch einiges tut. Gerade wenn man einen mockserver anwirft, der mit dem Adapter echte Daten austauscht.
@jey-cee
Die Frage nach dem Zeitaufwand für die Adapterentwicklung und Maintenance ist wirklich berechtigt.
Meine obigen Aspekte sind natürlich auch mit dem Verfolgen des Forums oder nun der Entwicklerseite machbar. Wendet man aber nicht die Zeit auf, dann wird man quasi kalt erwischt und es ist für einen selbst hektisch und gefühlt zu schnell.
D.h. zu der eigentlichen Entwicklung oder den Adapter auf Stand zu halten kommt ein nicht unwesentlicher Teil sich in die Dinge zu vertiefen.
Parallel möchte man aber auch gern andere neue Dinge/Adapter/Vis ausprobieren.Am Ende fehlt irgendwie die Zeit.
Und ja, auch ich habe mir schon des öfteren gesagt, daß ich keinen weiteren Adapter entwickeln sollte, da es doch recht viel Zeit in Anspruch nimmt.
Die Doku wird besser, aber auch die richtige Info finden ist immer noch eine Herausforderung. Immerhin gibt es nach dem aufmerksamen Lesen diese Threads einige neue Anlaufstellen, die ich vorher nicht kannt. In Vergangeheit war in der Tat eher „wie wurde es in einem anderen Adapter gelöst“ zielführender.
Ein Hinweis zur Doku, vielfach reflektiert die Doku den Zustand als solches, was aber eine sinnvolle Verwendung oder best practice ist, ist meist nicht der Fokus, aber genau das hilft meist erst recht weiter für das Verständnis.Gruß
Klaus -
@foxthefox sagte in Core-Entwicklung zu schnell?:
Ich bin ein großer Fan von automatisierten Tests und Konsistenzprüfungen. Da hätte ich den Wunsch, daß sich hier bei den Integrationstests noch einiges tut. Gerade wenn man einen mockserver anwirft, der mit dem Adapter echte Daten austauscht.
Ich hab das in ein paar meiner Adapter drin (und auch ein paar Core-Adapter haben das recht viel wie sql/influxDB und History, auch MQTT, ical ...), teilweise sehr "exzesiv" ... und ehrlich: Der Aufwand das mit einer sinnvollen Abdeckung hinzubekommen war dabei mindestens so groß wie es den Adapter und die Lib zusammen zu schreiben
Den Aufwand sind nur wenige Entwickler bereit zu investieren. Auch weil ggf der Aufwand das ausgewählte Device oder den Service zu Mocken sehr schwierig (bis teilweise unmöglich). technisch möglich ist fast alles was mocking angeht ... HTTP sehr easy, aber auch Serialport und andere Network-Protokolle gehen ... man geht aber je nach Protokoll sehr tief runter und muss sich in vieles einarbeiten was sonst zB eine Lib die man nutzt für einen wegkapselt Rein faktisch kannst Du das alles mit dem testing Framewerk (sowohl alt wie auch neu) alles machen, wobei wir noch wenige Adapter haben die mit dem neuen Framework hier umfangreiche Tests gebaut haben.
-
@apollon77 sagte in Core-Entwicklung zu schnell?:
@foxthefox sagte in Core-Entwicklung zu schnell?:
Ich bin ein großer Fan von automatisierten Tests und Konsistenzprüfungen. Da hätte ich den Wunsch, daß sich hier bei den Integrationstests noch einiges tut. Gerade wenn man einen mockserver anwirft, der mit dem Adapter echte Daten austauscht.
Ich hab das in ein paar meiner Adapter drin (und auch ein paar Core-Adapter haben das recht viel wie sql/influxDB und History, auch MQTT, ical ...), teilweise sehr "exzesiv" ... und ehrlich: Der Aufwand das mit einer sinnvollen Abdeckung hinzubekommen war dabei mindestens so groß wie es den Adapter und die Lib zusammen zu schreiben
Den Aufwand sind nur wenige Entwickler bereit zu investieren. Auch weil ggf der Aufwand das ausgewählte Device oder den Service zu Mocken sehr schwierig (bis teilweise unmöglich). technisch möglich ist fast alles was mocking angeht ... HTTP sehr easy, aber auch Serialport und andere Network-Protokolle gehen ... man geht aber je nach Protokoll sehr tief runter und muss sich in vieles einarbeiten was sonst zB eine Lib die man nutzt für einen wegkapselt Rein faktisch kannst Du das alles mit dem testing Framewerk (sowohl alt wie auch neu) alles machen, wobei wir noch wenige Adapter haben die mit dem neuen Framework hier umfangreiche Tests gebaut haben.
Ich mach es ja im neuen Framework auch schon mit dem fritzdect und musiccast
Ja, die wenigsten nutzen es überhaupt und noch weniger nutzen wahrscheinlich das Framework aus dem template.
Und ja, das ist aufwendig, aber hat sich bei meinen beiden Adaptern gelohnt. Man injiziert die unbekannten Antworten und der Adapter spuckt die gleichen Fehler in der eigenen Umgebung aus.
Wahrscheinlich wär es damals das Beste gewesen im neuen Framework die alten Tests zu belassen, aber die Möglichkeit hatte ich damals nicht erkannt (und man will ja auch auf Stand sein.)
-
@foxthefox sagte in Core-Entwicklung zu schnell?:
Ein Hinweis zur Doku, vielfach reflektiert die Doku den Zustand als solches, was aber eine sinnvolle Verwendung oder best practice ist, ist meist nicht der Fokus, aber genau das hilft meist erst recht weiter für das Verständnis.
Du kannst dir ja mal das aktuelle rohe Gerüst anschauen und uns gerne Issues erfassen, wenn dir das etwas fehlt.
Genau eine solche Doku wie du sie wünschst scheint mir absolut wichtig und zentral. Aber es ist auch wichtig, dass wir Feedback wie deines (auf dem richtigen Weg) erhalten und als Basis für die Aktualisierung verwenden.
