بصفتكم مطوري Rails، ستشغّلون الكثير من الـ specs. نستخدم guard غالبًا لأتمتة العملية أثناء التطوير، أو نستخدم --only-failures لإصلاح بعض الـ specs الفاشلة بسرعة. لكن في مسارات CI لدينا نحتاج إلى تشغيل المجموعة كاملة للتأكد من أن كل شيء أخضر قبل الـ merge أو الـ deploy. في جميع مشاريع Rails لدينا نستخدم GitHub Actions لتشغيل كل فحوصات CI. عادة نشغّل Pronto للتحقق من التزام الكود بمعايير Rubocop، و RSpec للتأكد من أننا لم نكسر شيئًا. ونشغّل هذه الـ actions مع كل push إلى Pull Request، ومع كل merge إلى فرعَي develop وmaster. في المشاريع الجديدة تكون هذه العملية سريعة عادة، دقيقتين ربما، لكن بعض مشاريعنا الأقدم قد يستغرق تشغيل مجموعة اختباراتها الكاملة أكثر من 10 دقائق. في العام الماضي انضممت إلى أحد أطول مشاريعنا عمرًا، وأخذت على عاتقي فورًا تقليص مدة تشغيل مجموعة الاختبارات. حين انضممت كانت المجموعة تستغرق أكثر من 19 دقيقة. أول ما فعلته أنني شغّلت المجموعة مع خيار profile، فحصلت على أبطأ 10 أمثلة. وكل مثال كان يستغرق أكثر من ثانيتين نال نصيبه من الاهتمام لأرى إن كان بإمكاني تسريعه. معظم هذه الـ specs كانت تعتمد على منطق تجهيز وتنظيف (setup وteardown) كثيف، فانتقلت إلى استخدام stubbing، ما قلّص زمن تشغيل كثير منها بشكل كبير. وفي الوقت نفسه غيّر أحد الزملاء آلية مطابقة استجابات json لدينا، فانخفضت المدة أكثر. ونجحنا في خفض زمن المجموعة إلى نحو 8 دقائق، وكان ذلك إنجازًا لافتًا حقًا. وبقيت لدي حيلة أخيرة: Parallel Tests!

كيف تعمل الاختبارات المتوازية؟

المنطق بسيط جدًا. معظم الحواسيب تحتوي على أكثر من نواة معالج، لكننا حين نشغّل RSpec نستخدم واحدة منها فقط. تتحقق أداة Parallel Tests من عدد الأنوية المتاحة على الجهاز الحالي، ثم تقسم مجموعة الاختبارات إلى عدد مماثل من المجموعات. وتعمل كل مجموعة على نواتها الخاصة، بقاعدة بيانات وعمليات أخرى مستقلة، حتى تبقى الاختبارات معزولة كلٌّ في نواتها. تكشف parallel_tests عن متغير ENV يُعلم الكود بمجموعة الاختبارات التي تعمل حاليًا، فيمكنكم تعديل منطق تشغيل الخدمات بناءً على هذا المتغير. فإذا كنا نستخدم مثلًا PORT 9250 لـ elasticsearch في الـ specs، يمكننا تغييره إلى:

9250 + ENV['TEST_ENV_NUMBER'].to_i

ونحتاج أيضًا إلى فعل الشيء نفسه مع اسم قاعدة البيانات:

test:
  database: hello_world<%= ENV['TEST_ENV_NUMBER'] %>

الآن إذا شغّلنا RSpec يدويًا فستكون قاعدة البيانات hello_world، أما إذا شغّلناه عبر parallel_tests فستكون لدينا عدة قواعد بيانات، مثل hello_world وhello_world2 وhello_world3 وhello_world4 وقبل تشغيل الاختبارات نحتاج إلى إعداد قواعد البيانات هذه بالمهمة التي توفرها parallel_tests.

rake parallel:setup

ولتشغيل الـ specs بالتوازي، نغيّر ببساطة الأمر من rspec إلى parallel_tests

# bundle exec rspec spec
rake parallel:spec

هذا كل شيء! أصبحنا الآن نشغّل الـ specs بالتوازي قبل Rails 6. وبهذا التغيير البسيط انخفضت مدة مجموعة الاختبارات من 8 دقائق إلى 4 دقائق على GitHub، الذي يستخدم أجهزة بنواتين لتشغيل الـ actions. وعلى أجهزة بأربع أنوية يمكننا تشغيل الـ specs في دقيقتين إلى 3 دقائق. وهذا تحسن هائل مقارنة بأكثر من 19 دقيقة كانت تستغرقها في البداية.