Ciao Community di Discourse! 
Ho lavorato sulla tecnologia (Colimit) che aiuta le persone ad applicare il Model-based testing per testare il loro frontend web/browser/DOM, backend API, o anche modelli ORM o view-model. Se non hai familiarità con l’idea, in pratica definisci una specifica di alto livello di ciò che la tua app dovrebbe fare in termini di possibili azioni che possono essere intraprese, e da quella ottieni centinaia o migliaia di sequenze di azioni utente valide (cioè flussi utente) che possono esplorare in modo intelligente un ampio spazio di stati di possibilità e scoprire bug difficili da raggiungere rispetto ai casi di test scritti a mano.
Sto uscendo dalla fase di utilizzo di Colimit su piccoli esempi e ho pensato a Discourse come un possibile ottimo candidato su cui provarlo successivamente, perché è sia un’app sofisticata che è in produzione ma è anche completamente open source, rendendola facile da modificare. La cosa interessante è che Colimit è scritto in modo astratto in modo da poter riutilizzare la stessa specifica/modello (scrivendo adattatori) per fare diversi stili di test come ad esempio i test API di Discourse tramite la gemma, rispetto ai test di integrazione che utilizzano Capybara, rispetto ai test smoke che utilizzano Puppeteer, ecc.
Prima di iniziare, mi chiedevo se qualcuno della community di Discourse potesse pensare a delle aree dell’app che sono attualmente fonti importanti di bug o che hanno una minore copertura su cui potrebbe essere più prezioso concentrare il tempo?
Inoltre, solo per curiosità , apprezzerei qualsiasi risposta da persone che pensano che questo suoni interessante e vedono un potenziale valore per testare il progetto Discourse, o se l’opinione è che lo stato attuale dei test sia già abbastanza buono (nel qual caso c’è ancora almeno un possibile valore di manutenzione dal poter sostituire i test scritti manualmente con quelli che potrebbero essere generati automaticamente da un modello).
Grazie!