Stabilitätspunkte, Abhängigkeitsaktualisierung & Codequalität

Entwicklung
1

Hallo zusammen!

Die beiden großen Entwicklungen des Moments: Multi-User & Bluetooth-Präsenz in Gladys 4 wurden gerade gemerged, ich denke, es ist Zeit, eine kleine Pause bei den Funktionen einzulegen und etwas Zeit in Stabilität, große Updates der Abhängigkeiten und Codequalität zu investieren.

Ich denke, es ist gesund, das regelmäßig zu tun, um sicherzustellen, dass das Projekt weiterhin die gleiche Qualität wie zu Beginn hat!

Abhängigkeiten:

  • Davon sprach ich gestern, es wird kritisch, den Build-Prozess des Frontends zu überarbeiten, der immer noch unter preact-cli@2.0.0 blockiert ist: Mise à jour du build du front (preact-cli@2 actuellement)

  • Bei der DB sind wir derzeit unter Sequelize 4, während Sequelize 6.5.0 veröffentlicht wurde. Ich denke, es gibt viele kleine Optimierungen/Bugfixes, die zwischen diesen beiden Versionen herausgekommen sind, und es würde dem Projekt gut tun, zu aktualisieren!

  • Wir sind immer noch bei Node 12.xx, während Node 14 die aktuellste LTS-Version ist.

  • Auf der Frontend-Seite müssen wir momentjs entfernen, das super schwer ist und veraltet ist! datejs, das wir im Frontend verwenden, macht genauso gut seinen Job, aber leichter.

  • vis-data und vis-network nehmen einen riesigen Platz für nicht viel ein, es lohnt sich wirklich, sie zu entfernen.

  • unistore, die State-Management-Bibliothek, die wir verwenden, wurde aktualisiert und ich denke, wir sollten wirklich darauf umsteigen! Übrigens, generell denke ich, wir sollten aufhören, sie für Komponentendaten zu verwenden, und uns auf globale Variablen beschränken (httpClient, user, das ist so ziemlich alles :p). Wir haben eine ganze Reihe von kleinen Bugs, die darauf zurückzuführen sind, dass wir diesen globalen Store verwenden, um lokale Komponentenzustände zu speichern. Das war ich, der das eingerichtet hat, zu Unrecht :slight_smile:

Was denkt ihr?

2

Gibt es eine Verwirrung zwischen Frontend und Backend, oder werden momentjs UND datejs parallel im Frontend verwendet?

Eine Menge brauchen? Das heißt :sweat_smile:

Für den Rest bin ich voll und ganz einverstanden, auch wenn ich noch nicht helfen kann. Stabilität ist super wichtig und eine Neuimplementierung ist oft notwendig, das hast du in 4 Versionen von Gladys regelmäßig gezeigt.. Chapeau :slight_smile:

3

momentjs und datejs werden auf der Frontend-Seite verwendet. Eigentlich haben wir Glück, momentjs wird nur an einer Stelle verwendet: der Kalender :slight_smile: Das ist meine Schuld, ich habe das in der PR-Überprüfung durchgehen lassen, aber klar müssen wir uns von momentjs trennen.

*einen verrückten Platz nehmen :slight_smile: Entschuldigung, ich habe ein Wort verpasst!

Top!

Tatsächlich denke ich, dass in jedem IT-Projekt man sich daran gewöhnen sollte, mindestens 20% der Zeit für die Reduzierung der technischen Schuld zu verwenden. Das ermöglicht es, ein Projekt aktuell, wartbar und sauber zu halten :slight_smile:

4

@AlexTrovato @cicoub13 @VonOx Ich weiß nicht, ob ihr meinen Post gesehen habt. Was haltet ihr davon?

5

preact-cli@3

Ja, aber ich denke, dass die großen Frontend-Änderungen heute schwierig sind, weil es keine Tests gibt. Ähnlicher Kommentar für unistore weiter unten.

Ist die Idee, ein leeres Projekt mit Version 3 neu zu initialisieren und den Gladys-Code in dieses neue Projekt zu kopieren?

Sequelize 6.5.0

Wenn wir SQLite behalten, dann los mit dieser Version. Ich kann helfen

Node 14

Ich sehe bereits den Merge Request und das sollte relativ einfach sein

momentjs durch datejs ersetzen

Ja, ähnlich: Viele manuelle Tests auf der Frontend-Seite

vis-data und vis-network

Ich weiß nicht, wofür das gut ist, ich denke, wir können es entfernen.

unistore

Was würdest du stattdessen für den Frontend-Store verwenden?

6

@pierre-gilles ich denke tatsächlich, dass es notwendig ist und dass es etwas ist, das man « tagtäglich » machen sollte und nicht 6 Monate warten, um es zu tun.

Wie @cicoub13 sagt, gibt es keine Themen auf der Frontend-Seite. Vielleicht sollten wir etwas Zeit für Frontend-Tests vor Migrations-/Änderungen aufwenden, um sicherzustellen, dass bestimmte Regressionstests durchgeführt werden, auch wenn dies die Tests durch einen Menschen nicht ersetzen wird.
Davon hatten wir bereits gesprochen, und wenn ich mich richtig erinnere, hatten wir https://www.cypress.io/ erwähnt.

Ich denke, wir werden uns damit beschäftigen müssen.

Das Beste wäre also, dass wir die Aufgaben aufteilen, und nichts hindert uns daran, mit den Migrations ohne die Cypress-Tests zu beginnen.

Wer übernimmt was? (ich übernehme nodejs v14 :stuck_out_tongue: )
Persönlich nicht so heiß auf die DB,
aber ich würde mich gerne an Cypress wagen, zumindest um die Grundlagen zu legen und Tests auf dem « core » einzuführen (man wird nicht geduldig sein müssen, es ist eine Entdeckung für mich).

7

Ich schau mal zu :sweat_smile:

Gleich, das sollte in meinem Bereich liegen

EDIT: Das React-Component unterstützt dayjs nicht :confused:

8

Ein anderes, aber eng verwandtes Thema: Wir haben Abhängigkeiten mit Sicherheitslücken der Stufe high (12 Frontend und 4 Backend). Ich weiß, dass die meisten Installationen nicht im Web geöffnet sind, aber ich denke, es ist besser, diese Abhängigkeiten zu aktualisieren.

Ich denke, es lohnt sich, DependaBot zu aktivieren: Configuring Dependabot version updates - GitHub Docs

9

Lol du findest immer eine Ausrede, um nicht zu machen!! :stuck_out_tongue:

10

10000% dafür!
Mindestens die Suche nach Schwachstellen im Code zu automatisieren und dies in den PRs zu blockieren, ist eine gute Idee, um ein Mindestmaß an Sicherheit zu gewährleisten.

11

Ich denke, die Tests müssen zuerst durchgeführt werden.

12

Ich bin für die allgemeine Wartung, das ist tagtäglich :slight_smile: (Node-Version, Minor/Patch-Updates der Abhängigkeiten, Codequalität).

Aber bei großen Änderungen, die dem Benutzer/Projekt nichts bringen, bin ich nicht unbedingt für den Wettlauf um Abhängigkeiten.

Wir haben trotzdem sehr begrenzte Mittel im Projekt, und ehrlich gesagt, wenn du absolut allen Abhängigkeiten folgst und sie sofort aktualisierst, sobald eine neue Version erscheint (ich spreche nicht von Sicherheitsupdates), dann entwickelst du nicht mehr.

Sequelize/tabler/etc… sie haben ein sehr viel höheres Tempo bei Breaking-Updates, als wir es täglich absorbieren könnten. Deshalb muss man bei diesen Updates die Pro- und Contra-Argumente abwägen und bewerten, ob die Vorteile größer sind als die Zeit, die man für andere « interne » Funktionen von Gladys aufwenden könnte.. :slight_smile:

Ich bin einverstanden!

Ich bin heiß darauf, dass wir uns Cypress zuwenden :slight_smile:

Ich denke, niemand hier hat jemals Cypress gemacht, also im Grunde müssten wir zusammen vorankommen. Wenn du dich ansehen möchtest, um ein POC zu erstellen, und wir dann alle zusammen faktorisieren? Ich kann auch von meiner Seite aus schauen :slight_smile:

oh Mist? Ist das zu 100% sicher? Wir könnten entweder einen PR vorschlagen oder einen Hack finden, damit es funktioniert.. sonst ist globalize oder date-fns weniger schlimm als moment

Ich habe es gesehen, das ist auch das Ziel dieses Stabilitätspunkts :slight_smile:

Ich habe bereits dependabot für den « Benachrichtigungsteil » im Repo aktiviert, aber für den « automatisierten PR-Teil » bin ich eher dagegen.

Bei einem Projekt in der Größe von Gladys gibt es Dutzende/Hunderte von PRs pro Tag, das füllt die PRs und die CI komplett aus, und es ist einfach unmöglich, so schnell zu sein wie er :stuck_out_tongue:

Dafür bin ich :slight_smile: man muss ein « npm audit » in die CI einbauen und nur auf die « high/critical » Schwachstellen blockieren :slight_smile:

13

Okay, ich habe bereits mit dem POC für Cypress begonnen. Ich denke, ich werde ein paar Seiten (Login, Dashboard, Registrierung) erstellen, um die verschiedenen Aspekte zu sehen und die Integration in GitHub Actions wahrscheinlich.
Ich werde versuchen, einen Bericht über offene Fragen und andere Schwierigkeiten zu führen, auf die ich stoße.
Sobald ich etwas habe, werde ich es teilen, damit wir darüber diskutieren können.

14

Guten Abend zusammen, falls jemand mitspielen oder die Einrichtung von Cypress kommentieren möchte:

Die Dokumentation (die sich mit der Experimentierung weiterentwickelt):

Und jetzt spiele ich mit den GitHub-Aktionen, um das Ganze zu automatisieren, das ist eigentlich ganz gut, aber natürlich wird das die Build-Zeit verlängern:
https://github.com/atrovato/Gladys/runs/2041711952?check_suite_focus=true

15

Hallo @AlexTrovato! Super Arbeit, hier sind meine Antworten auf deine offenen Fragen:

  1. Namensgebung für Testdateien:
  2. Ich denke, wir sollten nicht alle unsere Dateien index.js nennen, sondern versuchen, die funktionalen Fälle pro Datei aufzuteilen
  3. 1 Datei pro Fall? (login_success.js / login_error.js)

Eine Datei pro Fall erscheint mir enorm, findest du nicht? Auf der Serverseite haben wir eine Testdatei pro Datei in Gladys, in der Regel eine Datei pro Funktion. Und dann testen wir in der Datei Fall für Fall, das erscheint mir sauberer, sonst gibt es sehr viele Dateien, oder?

  1. snake_case vs camelCase?

Auf der Frontseite ist es CamelCase mit der ersten Buchstabe großgeschrieben, ich denke, wir sollten die gleiche Regel für die Testdateien beibehalten.

  1. Front in Entwicklung oder Produktion starten?

Ich habe keine Erfahrung mit Cypress, um zu wissen, was die Best Practice ist.

  1. Sollte auch der Server gestartet werden? Oder die Antworten mocken?
  2. Wenn wir den Server starten, können wir die Dienste/Integrationen nicht testen
  3. Wenn wir die Antworten mocken, mehr Arbeit, schwerer zu warten

Gute Frage. Für mich wäre der Vorteil von Mocking, dass es für die Dienste wäre, aber der Nachteil ist, dass potenziell, wenn sich eine API-Route im Backend-Code ändert und die Mocks nicht aktualisiert werden, die Frontend-Tests bestehen, obwohl es in der echten Welt scheitert. Es ist weniger End-to-End.

Vielleicht wäre ein « hybrider » Ansatz möglich?

Wir mocken alles, was Dienste sind, und die API von Gladys Core (Login, etc.) wird nicht gemockt, damit wir sicher sein können, dass die kritischen Routen (Login, Passwort vergessen, Anmeldung) gut im E2E funktionieren.

  1. Wie kann man erkennen, dass die Front bereit ist, um die Tests automatisch zu starten?

Dazu habe ich keine Erfahrung mit Cypress, da wird man recherchieren müssen.

  1. Wie kann man die Sprache des Browsers « sauber » verwalten?

Dafür muss es doch einen Weg in Cypress geben, oder?

16

Hallo,

Ich kenne Cypress nicht wirklich, aber wenn das Ziel End-to-End-Tests sind, sollte man die APIs dahinter tatsächlich belassen, da der Sinn darin besteht, die Zusammenstellung der verschiedenen Komponenten zu testen.
Wenn das Ziel jedoch eher unitäre Tests auf der Frontend-Seite sind, dann ist es besser, alles zu mocken, auch die Core-API.

Ich denke, man braucht beide Arten von Tests: die End-to-End-Tests, die tatsächlich sicherstellen, dass alle Komponenten korrekt zusammenarbeiten, und die Unit-Tests, die zeigen, ob eine Komponente ein Problem hat oder nicht.

Bei Unit-Tests geht es im Wesentlichen darum, das Verhalten der Komponente in allen möglichen Fällen zu überprüfen.
Das bedeutet, dass man die Props, die man ihr übergibt, testet: Wenn eine Komponente eine Number-Prop erwartet, testet man mit einer Number, dann mit einem String, dann mit null usw., um sicherzustellen, dass alle Fälle korrekt behandelt werden,
wenn es Events gibt, überprüft man, ob diese korrekt aufgerufen werden, ob sie korrekt aufgerufen werden (ein Click-Event sollte nur einmal aufgerufen werden usw.), usw…
Man testet auch die Zustandsänderungen, wenn nötig (im Wesentlichen, wenn ein Button einen Loading-Zustand hat, muss man überprüfen, dass, wenn der Loading-Zustand aktiv ist, der Button die richtige Darstellung hat, er hat zum Beispiel die Klasse loading usw…)

Das sind die lästigsten Tests, bei kleinen Komponenten geht es schnell, sobald es sich um eine komplexere Komponente handelt, wird es chaotisch ^^
Es scheint mehrere Möglichkeiten zu geben, diese Tests zu verwalten, in der Preact-Dokumentation wird Enzyme oder die Preact Testing Library erwähnt, die es ermöglichen, Unit-Tests auf einfachere Weise durchzuführen, aber nun ^^ (Unit Testing with Enzyme – Preact Guide oder Testing with Preact Testing Library – Preact Guide)

17

Ich habe mich darum gekümmert, moment aus dem Frontend zu entfernen. Ich habe es durch dayjs ersetzt, dafür musste man zusätzlich die beiden Plugins localizedFormat und localeData laden. Da die API von dayjs sehr ähnlich zu der von moment ist, funktioniert es gut. Falls sich langfristig Probleme ergeben, habe ich gesehen, dass wir in ScheduledTrigger date-fns verwenden, das ebenfalls mit react-big-calendar kompatibel ist. Wir können uns dann darauf umstellen.

18
  1. Soll der Server ebenfalls gestartet werden? Oder die Antworten mocken?
  2. Wenn wir den Server starten, können wir die Dienste/Integrationen nicht testen
  3. Wenn wir die Antworten mocken, mehr Arbeit, schwerer zu warten

Ich folge dir, um die Integration im Core zu testen und die Dienste zu mocken (zumindest für die Erfolgsfälle), wir können leicht beide kombinieren.
Ich werde den aktuellen PR ergänzen, um ein Beispiel für beide Fälle bereitzustellen.
Daher denke ich, dass dies das Testen im „Produktionsmodus“ ermöglicht, um das Ziel zu validieren, im „E2E“-Modus, außer für die Dienste.

  1. Wie kann man erkennen, dass das Frontend bereit ist, um die Tests automatisch zu starten?

Github Actions kann das tun, es gibt die Option in der PR CI.

  1. Wie kann man die Sprache des Browsers „ordentlich“ verwalten?

Ich denke, meine Frage ist eher: Sollten wir Tests für die Beschriftungen durchführen? Das könnte ziemlich aufwendig werden. Aber um die Fehlermeldungen je nach Fall zu validieren, kann das nützlich sein.
Ansonsten wird es über Variablen/Konfiguration der Ausführung sein.

19

Ok, gute Idee!

Nice :slight_smile:

Ich würde sagen, das kommt auf den Fall an. Tatsächlich könnte es für Fehler gut sein. Vor allem für bestimmte „kritische“ Seiten (Login, Anmeldung), bei denen man wirklich alles abdecken muss.

Ansonsten ist es nicht nötig, es könnte redundant und aufwendig sein :slight_smile:

20

@bertrandda ich habe gerade bemerkt, dass der Caldav-Dienst momentan auf der Backend-Seite verwendet wird, es wäre cool, das auch hier zu ändern :slight_smile: