Test & Dokumentation
Opened this issue · 7 comments
Im Augenblick beschränkt sich die Dokumentation für den Brauhelfer auf eine große Tabelle mit Formeln. Die Implementierung enthält keinerlei Dokumentation und das Datenmodell muss man sich Reverse-Engineeren. Tests gibt es gar nicht.
Nun interessiert mich welche Pläne es da schon gibt. Ansonsten würde ich einen Vorschlag mit QTest und dem Zusammenspiel der Proxymodelle ausarbeiten. Das Datenmodell würde ich mir nebenbei noch anschauen, da es eng mit den Proxy-Modellen verbunden ist.
Wenn Du erklärst was ein QTest und ein Proxymodell ist und wofür das gut ist… und welchen Erkenntniswert Du Dir abseits des Theoretischen in Abgleich zwischen Ertrag und eingesetzter Arbeitszeit Du Dir versprichst…
Du darfst nicht vergessen: Das ist ein Hobbyprojekt und kein Testprojekt einer IT-Firma noch eine studentische Projektarbeit an einem IT-Lehrstuhl.
Du kennst den Feature-Erhaltungssatz? Du fügst deiner Software ein Feature hinzu und machst unbemerkt ein anderes Feature kaputt.
Denn Softwareprogrammierung ist abstrakt, komplex und viel von beidem. Den einzigen Ausweg bietet regelmäßiges Testen. Andernfalls bist du bald nur noch mit Bugfixen beschäftig, statt mit Erweiterungen und Änderungen.
Die QT-Proxy-Modelle funktionieren scheinbar nicht richtig. Nach einem Tag sinnlos rumprobieren hab ichs dann gelassen.
Du kennst den Feature-Erhaltungssatz? Du fügst deiner Software ein Feature hinzu und machst unbemerkt ein anderes Feature kaputt.
Denn Softwareprogrammierung ist abstrakt, komplex und viel von beidem. Den einzigen Ausweg bietet regelmäßiges Testen. Andernfalls bist du bald nur noch mit Bugfixen beschäftig, statt mit Erweiterungen und Änderungen.Die QT-Proxy-Modelle funktionieren scheinbar nicht richtig. Nach einem Tag sinnlos rumprobieren hab ichs dann gelassen.
Unter dem Begriff kenne ich das nicht, aber was Du beschreibst, ist in jüngster Zeit mehrfach vorgekommen. Was ein QT-Proxy-Modell ist, weiß ich nicht. Ich mache hier nur die Texte.
Der KBH ist nicht übermäßig komplex. Nur wenige Felder spielen in andere Tabs hinein. Ob regelmäßige Tests den Aufwand rechtfertigen - ich wäre zumindest skeptisch. Die Community im Forum hobbybrauer.de ist da sehr aktiv. Das ist ein niederschwelliges Verfahren, es genügt aber bisher, soweit ich das beurteilen kann.
Das hier wäre ein Proxy-Modell.
https://github.com/kleiner-brauhelfer/kleiner-brauhelfer-2/blob/master/kleiner-brauhelfer-core/proxymodelsud.h
Der Trick hinter dem Proxy-Modell besteht in der Verknüpfung mehrere Datenrepresentation. Du änderst den Eintrag in einer Tabelle auf einem Tab, davon abhängig gibt es eine weitere Tabelle in einem anderen Tab. Durch die Proxy-Verknüpfung aktualisieren sich die Daten in allen Tabellen.
Wenn es nicht funktioniert, dann aktualisiert sich die abhängige Tabelle erst beim Neustarten der Anwendung.
Ich meine zu verstehen. Es werden also Abhängigkeiten eruiert. Und was sagt es aus, wenn das Proxymodell nicht funktioniert, wie Du eingangs erwähntest?
Aber egal - ich will nicht nerven, weil das nicht meine Baustelle ist. Mir ging es nur darum den möglichen Zeitaufwand zu hinterfragen.
Automatisiert erspart Testen langes rumklicken auf Oberfläche. Es schafft auch vertrauen, das eine Änderung funktioniert. Richtig dosiert, reduziert es Stress und man bleibt auf das Programmieren konzentriert.
Unit Test oder Integrationstest stehen überhaupt nicht auf dem Programm. Die Releases werden auch nur sehr oberflächlich getestet. Daher wäre ein automatisches Testing schon toll.
Im KBH wird das ProxyModel nur benutzt, um einen Teil des zugrundeliegenden Models anzuzeigen (filter), oder um die Daten zu sortieren.
Weiter solltest du beachten, dass der KBH aus zwei Teilen besteht. Das Core für die Datenbankabbildung und Datenbankmodell. Dieser Teil wird auch bei der Android App eingesetzt. Der zweite Teil ist die GUI. Im prinzip sind das unabhängige Projekte.