مرحباً بالفريق،
كنت أتطلع للمساهمة في مشروع Discourse، ولاحظت أن اختبارات RSpec الخاصة بكم يتم تحميلها في 0 ثانية!
هل هناك أي نصائح حول كيفية تقليل هذا الوقت، من فضلكم؟ في أحد مشاريعي، يستغرق الأمر حوالي 30 ثانية!
مرحباً بالفريق،
كنت أتطلع للمساهمة في مشروع Discourse، ولاحظت أن اختبارات RSpec الخاصة بكم يتم تحميلها في 0 ثانية!
هل هناك أي نصائح حول كيفية تقليل هذا الوقت، من فضلكم؟ في أحد مشاريعي، يستغرق الأمر حوالي 30 ثانية!
ما الأمر الذي قمت بتشغيله؟ ماذا حدث؟ ماذا كنت تتوقع أن يحدث؟
أنت تقول أن الوقت صفر، ولكنك تريده أقل من الصفر؟ مقدار الوقت الذي يستغرقه مشروعك لا علاقة له بالوقت الذي يستغرقه على Discourse، وهو مشروع ضخم به آلاف الاختبارات.
لا، كنت أتطلع إلى معرفة كيف صنعتها، من فضلك. أريد أن أفعل الشيء نفسه في مشروعي
تقول إن الوقت صفر، ولكنك تريده أقل من الصفر؟
لدي مشروعي الخاص الذي يستغرق 30 ثانية وأريد تقليل هذا الوقت لمشروع الـ rails الخاص بي، لذلك أستخدم هذا كفرصة تعليمية لمعرفة كيف قام فريق Discourse بتقليل تحميل ملفات المواصفات الخاصة بهم إلى الصفر.
أين رأيت ذلك؟ لأكون صادقًا، إذا كان هناك شيء يقول 0.0 ثانية، فمن المحتمل أن يكون خطأ في القياس ![]()
بعض الأشياء الرئيسية التي نستخدمها لتحسين أداء RSpec هي:
GitHub - grosser/parallel_tests: Ruby: 2 CPUs = 2x Testing Speed for RSpec, Test::Unit and Cucumber
test-prof/docs/recipes/let_it_be.md at master · test-prof/test-prof · GitHub (نحن نغلف هذا في مساعد fab! في قاعدة التعليمات البرمجية الخاصة بنا)
أعتقد أن هذا قد يكون أثرًا جانبيًا لاستخدام parallel_tests. العملية التي تكتب المخرجات لا تقوم بتحميل أي اختبارات في الواقع. بدلاً من ذلك، تقوم بتشغيل عمليات عاملة متعددة لتشغيل الاختبارات.
أرى ذلك، شكراً جزيلاً!
هل تعتقد أن استخدام سبرينغ (Spring) في التكامل المستمر (CI) فكرة جيدة؟