Hallo Discourse Community! 
Ich habe an einer Technologie (Colimit) gearbeitet, die es Menschen ermöglicht, Model-based testing anzuwenden, um ihr Web-/Browser-/DOM-Frontend, API-Backend oder sogar ORM-Modelle oder View-Modelle zu testen. Wenn Sie mit der Idee nicht vertraut sind, definieren Sie im Grunde eine High-Level-Spezifikation dessen, was Ihre App in Bezug auf mögliche Aktionen tun soll, und daraus erhalten Sie Hunderte oder Tausende von Sequenzen gültiger Benutzeraktionen (d. h. Benutzerflüsse), die einen großen Zustandsraum von Möglichkeiten intelligent durchsuchen und schwer zu erreichende Fehler aufdecken können, verglichen mit handgeschriebenen Testfällen.
Ich bin dabei, Colimit an kleinen Beispielen zu erproben, und dachte, Discourse wäre ein potenziell großartiger Kandidat, um es als Nächstes auszuprobieren, da es sich sowohl um eine hochentwickelte App handelt, die in der Produktion läuft, als auch um eine vollständig Open-Source-Anwendung, die sich leicht modifizieren lässt. Das Coole ist, dass Colimit abstrakt geschrieben ist, sodass Sie dieselbe Spezifikation/dasselbe Modell (durch Schreiben von Adaptern) wiederverwenden können, um verschiedene Teststile durchzuführen, wie z. B. die Discourse API-Tests über das Gem, die Integrationstests mit Capybara oder die Smoke-Tests mit Puppeteer usw.
Bevor ich beginne, wollte ich fragen, ob jemand aus der Discourse-Community Bereiche der App kennt, die derzeit große Fehlerquellen darstellen oder weniger abgedeckt sind und auf die es sich lohnen würde, Zeit zu konzentrieren?
Außerdem würde ich mich aus reiner Neugier über Antworten von Leuten freuen, die diese Idee interessant finden und Potenzial für das Testen des Discourse-Projekts sehen, oder ob die Meinung ist, dass der aktuelle Stand des Testens bereits gut genug ist (in diesem Fall gibt es immer noch einen möglichen Wartungswert, da manuell geschriebene Tests durch solche ersetzt werden könnten, die automatisch aus einem Modell generiert werden).
Danke!