أهلاً بمجتمع Discourse! 
لقد كنت أعمل على تقنية (Colimit) تساعد الأشخاص على تطبيق الاختبار القائم على النماذج لاختبار الواجهة الأمامية لتطبيقات الويب/المتصفح/DOM، أو الواجهة الخلفية لواجهات برمجة التطبيقات (API)، أو حتى نماذج ORM أو نماذج العرض. إذا لم تكن مألوفًا بالفكرة، فأنت تقوم بتعريف مواصفات عالية المستوى لما يفترض أن يفعله تطبيقك من حيث الإجراءات الممكنة التي يمكن اتخاذها، ومن ذلك تحصل على مئات أو آلاف التسلسلات من إجراءات المستخدم الصالحة (أي تدفقات المستخدم) التي يمكنها الزحف بذكاء عبر مساحة حالة كبيرة من الاحتمالات واكتشاف الأخطاء التي يصعب الوصول إليها مقارنةً بحالات الاختبار المكتوبة يدويًا.
أنا خارج مرحلة استخدام Colimit على أمثلة صغيرة وفكرت في Discourse كمرشح رائع محتمل لتجربته بعد ذلك، لأنه تطبيق متطور يتم تشغيله في الإنتاج ولكنه أيضًا مفتوح المصدر بالكامل، مما يجعله سهل التعديل. الشيء الرائع هو أن Colimit مكتوب بطريقة مجردة بحيث يمكنك إعادة استخدام نفس المواصفات/النموذج (عن طريق كتابة محولات) للقيام بأنماط مختلفة من الاختبارات مثل اختبارات واجهة برمجة تطبيقات Discourse عبر الجيم (gem)، مقابل اختبارات التكامل باستخدام Capybara، مقابل اختبارات الدخان باستخدام Puppeteer، إلخ.
قبل البدء، كنت أتساءل عما إذا كان أي شخص من مجتمع Discourse يمكنه التفكير في أي مجالات في التطبيق تمثل حاليًا مصادر رئيسية للأخطاء أو لديها تغطية أقل يمكن أن يكون التركيز عليها أكثر قيمة؟
أيضًا، بدافع الفضول فقط، سأقدر أي ردود من الأشخاص الذين يعتقدون أن هذا يبدو مثيرًا للاهتمام ويرون قيمة محتملة لاختبار مشروع Discourse، أو إذا كان الرأي هو أن الحالة الحالية للاختبار جيدة بما فيه الكفاية بالفعل (في هذه الحالة لا يزال هناك على الأقل قيمة صيانة محتملة من القدرة على استبدال الاختبارات المكتوبة يدويًا بتلك التي يمكن إنشاؤها تلقائيًا من نموذج).
شكرًا!