Ich habe deinen Betrag mal in einen neuen Thread verschoben.
Testing ist bei so einem kleinen Projekt immer ein Problem.
Aus diesem Grund verfolge ich so hartnäckig die
Pipe und Filter-Struktur. Änderung bleiben in den jeweiligen Filtern(=Module). Wenn man neue Module hinzufügt, gefährden diese nicht die Stabilität der anderen Module.
Aber ja. Das (angemessene) Testen ist eine Herausforderung, die ich schon jetzt nicht mehr leisten kann.
Der Sourcecode hat knapp 17.000 Zeilen und ich habe 4 Architekturen (ESP8266, ESP8285, ESP32 und jetzt den ESP32C3).
Unmöglich alle Architekturen für mich zu testen. Und wenn ich dann an die ganzen Module [*] denke,vergiss es.
Bei den ganzen hardwarenahen Entwicklung kannst du auch unit-Tests oder ähnliches vergessen.
Und ich werde meiner Release-Strategie treu bleiben. Aktuelle Versionen sind als Alpha/Beta markiert. Wenn sie sich stabilisieren und wenn schwere Bugs gefunden werden, werden sie zu Release-Versionen.
Wenn jemand eine ältere Version will, kann er sie ja über die jeweilige Release-Seite bei Github herunterladen und mit dem Flasher nutzen.
[*]
5 Klassen, die Befehle empfangen (DCC, Rocnet, Z21-Zentrale, Z21-Empfänger, Espnow)
14 Klassen, die Befehle verarbeitet (PWM-Ansteuerung, Led, ....)
7 Klassen, die auf Befehle reagieren
3 Klassen, die Displays ansteuern.