こんにちは、Discourseコミュニティの皆さん！
私は、人々がモデルベーステストをWeb/ブラウザ/DOMフロントエンド、APIバックエンド、あるいはORMモデルやビューモデルのテストに応用するのを支援する技術（Colimit）に取り組んでいます。このアイデアに馴染みがない方のために説明すると、基本的に、可能なアクションの観点からアプリが何をすべきかのハイレベルな仕様を定義し、そこから、手書きのテストケースと比較して到達しにくいバグを発見できる、広大な可能性の状態空間をインテリジェントにクロールできる何百、何千もの有効なユーザーアクションのシーケンス（つまり、ユーザーフロー）を取得します。
Colimitを小さな例で使う段階を終え、Discourseが次に試すのに最適な候補かもしれないと考えました。なぜなら、Discourseは本番環境で実行されている洗練されたアプリでありながら、完全にオープンソースであるため、いじりやすいからです。Colimitのクールな点は、抽象化された方法で書かれているため、同じ仕様/モデル（アダプターを記述することによって）を再利用して、たとえばGemを介したDiscourse APIテスト、Capybaraを使用した統合テスト、Puppeteerを使用したスモークテストなど、さまざまなスタイルのテストを実行できることです。
始める前に、Discourseコミュニティの誰か、現在バグの主な原因となっている、またはカバレッジが低い領域で、時間を集中する価値がより高いと思われるアプリの領域を思いつく人はいますか？
また、単に好奇心から、これがDiscourseプロジェクトのテストに価値があると考えている人からの返信、または現在のテストの状態がすでに十分であるという意見（その場合でも、モデルから自動生成できるテストで手動で記述されたテストを置き換えることができるという点で、少なくとも保守的な価値がある可能性があります）があれば、感謝します。
ありがとうございます！