--- title: "تشغيل الـ Specs بالتوازي قبل Rails 6" description: "جاء إصدار Rails 6 بميزة تشغيل الاختبارات بالتوازي، لكن هل تعلمون أن بإمكانكم فعل ذلك من قبله؟ نستخدم parallel_tests منذ أشهر لتشغيل اختبارات RSpec بالتوازي في GitHub action لدينا." canonical: https://oozou.com/ar/blog/running-specs-in-parallel-before-rails-6-84 locale: ar date: 2020-12-29 author: "OOZOU Team" --- # تشغيل الـ Specs بالتوازي قبل Rails 6 > جاء إصدار Rails 6 بميزة تشغيل الاختبارات بالتوازي، لكن هل تعلمون أن بإمكانكم فعل ذلك من قبله؟ نستخدم parallel_tests منذ أشهر لتشغيل اختبارات RSpec بالتوازي في GitHub action لدينا. Published: 2020-12-29 · Author: OOZOU Team (Engineering) · 3 min read بصفتكم مطوري Rails، ستشغّلون الكثير من الـ specs. نستخدم guard غالبًا لأتمتة العملية أثناء التطوير، أو نستخدم --only-failures لإصلاح بعض الـ specs الفاشلة بسرعة. لكن في مسارات CI لدينا نحتاج إلى تشغيل المجموعة كاملة للتأكد من أن كل شيء أخضر قبل الـ merge أو الـ deploy. في جميع مشاريع Rails لدينا نستخدم [GitHub Actions](https://docs.github.com/en/free-pro-team@latest/actions) لتشغيل كل فحوصات CI. عادة نشغّل [Pronto](https://github.com/marketplace/actions/pronto-action) للتحقق من التزام الكود بمعايير [Rubocop](https://github.com/rubocop-hq/rubocop)، و [RSpec](https://rspec.info/) للتأكد من أننا لم نكسر شيئًا. ونشغّل هذه الـ actions مع كل push إلى Pull Request، ومع كل merge إلى فرعَي develop وmaster. في المشاريع الجديدة تكون هذه العملية سريعة عادة، دقيقتين ربما، لكن بعض مشاريعنا الأقدم قد يستغرق تشغيل مجموعة اختباراتها الكاملة أكثر من 10 دقائق. في العام الماضي انضممت إلى أحد أطول مشاريعنا عمرًا، وأخذت على عاتقي فورًا تقليص مدة تشغيل مجموعة الاختبارات. حين انضممت كانت المجموعة تستغرق أكثر من 19 دقيقة. أول ما فعلته أنني شغّلت المجموعة مع خيار profile، فحصلت على أبطأ 10 أمثلة. وكل مثال كان يستغرق أكثر من ثانيتين نال نصيبه من الاهتمام لأرى إن كان بإمكاني تسريعه. معظم هذه الـ specs كانت تعتمد على منطق تجهيز وتنظيف (setup وteardown) كثيف، فانتقلت إلى استخدام stubbing، ما قلّص زمن تشغيل كثير منها بشكل كبير. وفي الوقت نفسه غيّر أحد الزملاء آلية مطابقة استجابات json لدينا، فانخفضت المدة أكثر. ونجحنا في خفض زمن المجموعة إلى نحو 8 دقائق، وكان ذلك إنجازًا لافتًا حقًا. وبقيت لدي حيلة أخيرة: [Parallel Tests](https://github.com/grosser/parallel_tests)! # كيف تعمل الاختبارات المتوازية؟ المنطق بسيط جدًا. معظم الحواسيب تحتوي على أكثر من نواة معالج، لكننا حين نشغّل RSpec نستخدم واحدة منها فقط. تتحقق أداة Parallel Tests من عدد الأنوية المتاحة على الجهاز الحالي، ثم تقسم مجموعة الاختبارات إلى عدد مماثل من المجموعات. وتعمل كل مجموعة على نواتها الخاصة، بقاعدة بيانات وعمليات أخرى مستقلة، حتى تبقى الاختبارات معزولة كلٌّ في نواتها. تكشف parallel_tests عن متغير ENV يُعلم الكود بمجموعة الاختبارات التي تعمل حاليًا، فيمكنكم تعديل منطق تشغيل الخدمات بناءً على هذا المتغير. فإذا كنا نستخدم مثلًا PORT 9250 لـ elasticsearch في الـ specs، يمكننا تغييره إلى: ```ruby 9250 + ENV['TEST_ENV_NUMBER'].to_i ``` ونحتاج أيضًا إلى فعل الشيء نفسه مع اسم قاعدة البيانات: ```yaml test: database: hello_world<%= ENV['TEST_ENV_NUMBER'] %> ``` الآن إذا شغّلنا RSpec يدويًا فستكون قاعدة البيانات hello_world، أما إذا شغّلناه عبر parallel_tests فستكون لدينا عدة قواعد بيانات، مثل hello_world وhello_world2 وhello_world3 وhello_world4 وقبل تشغيل الاختبارات نحتاج إلى إعداد قواعد البيانات هذه بالمهمة التي توفرها parallel_tests. ```shell rake parallel:setup ``` ولتشغيل الـ specs بالتوازي، نغيّر ببساطة الأمر من rspec إلى parallel_tests ``` # bundle exec rspec spec rake parallel:spec ``` هذا كل شيء! أصبحنا الآن نشغّل الـ specs بالتوازي قبل Rails 6. وبهذا التغيير البسيط انخفضت مدة مجموعة الاختبارات من 8 دقائق إلى 4 دقائق على GitHub، الذي يستخدم أجهزة بنواتين لتشغيل الـ actions. وعلى أجهزة بأربع أنوية يمكننا تشغيل الـ specs في دقيقتين إلى 3 دقائق. وهذا تحسن هائل مقارنة بأكثر من 19 دقيقة كانت تستغرقها في البداية. --- Contact OOZOU: hello@oozou.com · +66 2544 0000 · https://oozou.com/ar/contact More for AI agents: https://oozou.com/llms.txt · every page has a markdown twin at its URL plus ".md"