search

puzzle / okr

Open source OKR application
GNU Affero General Public License v3.0
12 stars 2 forks source link

Move Quarter Utils to test sources #983

Open pizzi-cato opened 3 months ago

pizzi-cato commented 3 months ago

Die H2 SQL Scripts verwenden statische Java-Funktionen, welche Quartalsberechnungen (Start-/Enddatum, Label) ermöglichen. Diese Hilfsklassen sind aktuell im src/main (produktiver Code), was äusserst unschön ist. Davon betroffen sind die Klassen

Ein geeigneter Ansatz soll gefunden werden, um die Hilfsklassen nach src/test (Test Code) zu verschieben, damit diese nicht mehr im produktiven Code vorhanden sind. Weiterhin müssen folgende Use Cases unterstützt werden:

Dies ist eine Folge-Story von https://github.com/puzzle/okr/issues/958 Fix H2 + JUnit Test für Quartal GJ 24/25-Q1

clean-coder commented 1 month ago

Analyse Behebung "äusserst unschöner" Dinge

Vorschlag "die Hilfsklassen nach src/test (Test Code) verschieben" Ich habe google und diverse AI-Service gefragt. Die haben jeweils "dirty Hacks" gezeigt, was eventuell helfen könnten. Es wurde aber immer abgeraten, diese auch zu verwenden. Fazit:

It's generally not recommended to call Java code directly from src/test/java because that folder is specifically for test-related code. Instead, refactoring the shared logic into src/main (or a shared module) makes it reusable and available for all your application and test needs.

Vorschlag "neues Maven Projekt" Ein eigenes neues Maven Projekt machen und dann inch.puzzle.okr auf das neuen Projekte verweisen. Könnte man ausprobieren, aber ziemlich viel Aufwand für nur 4 Klassen.

Vorschlag "neuen Java Modul" Den Code für die Quarter Berechnung in ein neues Java Modul verschieben. Das Problem ist, dass man zuerst das bestehende ch.puzzle.okr auf Java Module umschreiben müsste bevor man ein neues Modul für die Quarter Berechnung hinzufügen könnte. Schöner als das mit dem neuen Maven Projekt, aber sicher noch aufwendiger. Und es wäre von Vorteil wenn sich jemand mit Java Modulen in Kombination von Spring Boot auskenne würde.

Vorschlag "Tabula Rasa" Die bestehende Lösung zu unschön ist die "Modularisierung" (im Verhältnis zum Nutzen) gross ist, könnte man einfach die Java Klassen (+Tests) löschen und im V100_0_0__TestData.sql einfach 2 hard codierte Quartale einfügen wie bisher. Und alle 3 Monate muss das halt jemand anpassen. #958 und seine Vorarbeiten war dennoch nicht umsonst, denn nun habe wir nur mehr 2 Quartale (mit fixen IDs), deren Label und Datum Werte man manuell anpassen müsste.

clean-coder commented 1 month ago

POC "quarter_lib" Maven Projekt

Habe auf dem Branch https://github.com/puzzle/okr/tree/poc/983_quarter_lib den Versuch gestartet, den Code für Quarter Berechnungen in ein neues Maven Projekt zu verschieben. Dies funktioniert lokal super, auf dem GitHub Server aber leider nicht. Die Cypress Tests laufen nicht. Als Ursache hat sich herausgestellt, dass das backend die Klassen von quarter_lib nicht finden kann. Wenn man das Problem mal verstanden hat, macht es auch Sinn:

Potentieller Fix 1

Potentieller Fix 2

clean-coder commented 1 month ago

Feedback Christoph

Da diese Story (#983) von Christoph kommt, habe wir eine Informations Austausch zu diesem Thema gemacht. Da kam als Input eine seht gute Idee für eine Erweiterung/Anpassung. Im obigen Stand des POCs war ein manueller Schritt nötig (quarter_lib.jar manuell kopieren) und das jar musste dann fix in git eingecheckt. Dies kann man aber schöner lösen, indem man in quarter_lib ein Deploy step definiert, der das erstellte quarter_lib.jar in des richtige Verzeichnis vom backend Projekt kopiert (und automatisch die richtige Folder Struktur dazu erstellt). Und das jar muss nach auch nicht mehr im git sein.

Die nötigen Anpassungen in https://github.com/puzzle/okr/tree/refs/heads/poc/983_quarter_lib_maven_modules sind gemacht. Lokal kann man einfach ein mvn clean install machen und einmal noch ein mvn deploy --file quarter_lib/pom.xml. Damit der Build auf GitHub funktioniert, habe ich noch frontend-test-action.yml angepasst.