تحديثاتي كانت تحطم الميزات القديمة: كيف أنقذتني ‘الاختبارات التراجعية الآلية’ من جحيم الخوف عند كل إصدار؟

يا جماعة الخير، السلام عليكم ورحمة الله.

خلوني أرجع بالزمن شوي، لأيام ما كنت لسا مبرمج جديد متحمس، وكل سطر كود بكتبه بحس حالي فيه فتحت القسطنطينية. كنت شغال على نظام متجر إلكتروني كبير، وكان مطلوب مني أضيف ميزة جديدة: الدفع عن طريق محفظة إلكترونية حديثة. الموضوع ما كان معقد كتير، كم استدعاء API وشوية شغل على الواجهة الأمامية، وخلصنا.

بعد سهرة طويلة من الشغل والقهوة، رفعت التحديث وأنا كلّي ثقة. تاني يوم الصبح، صحيت على “زفّة” رسائل من مدير المشروع وفريق الدعم. “أبو عمر، الحقنا!”، “النظام خربان!”، “العملاء بشتكوا!”.

نزلت عالشغل وأنا مش فاهم إشي، يا ويلي شو صار! بعد ساعات من التدوير والتحقيق والضغط النفسي، اكتشفنا المصيبة: ميزة “تطبيق كوبون الخصم”، اللي كانت شغالة زي الليرة الذهب من سنين، بطلت تشتغل بالمرة! التغيير “البسيط” اللي عملته في سلة الشراء عشان أضيف طريقة الدفع الجديدة، ضرب ميزة تانية في الصميم وأنا مش جايب خبر.

يومها حسيت بإحباط ما بعده إحباط، وفقدت الثقة في كل كبسة “push” بعملها. صرت أخاف ألمس الكود القديم، وكل إصدار جديد صار بالنسبة إلي كابوس محتمل. هاي القصة كانت نقطة التحول اللي خلتني أبحث عن حل جذري، حل يرجعلي ثقتي ويخليني أنام مرتاح بالليل. الحل كان اسمه: الاختبارات التراجعية الآلية (Automated Regression Testing).

ما هي الاختبارات التراجعية (Regression Testing)؟ وليش هي “حبة مسكّن” لكل مبرمج؟

ببساطة شديدة، الاختبار التراجعي هو عملية إعادة اختبار الميزات الموجودة في برنامجك بعد إجراء أي تعديل أو إضافة ميزة جديدة. الهدف؟ نتأكد إنه التغيير الجديد ما “خرّب” أو “كسر” إشي كان شغال تمام من قبل. يعني زي لما تصلّح تسريب مي في المطبخ، بترجع تتأكد إنك ما فصلت الكهربا عن الثلاجة بالغلط.

كلمة “تراجعي” أو “Regression” بتعني “العودة إلى حالة أسوأ”. فالاختبار التراجعي هو الدرع اللي بيحمي برنامجك من هذا التراجع غير المقصود في الجودة.

ليش بعتبرها “حبة مسكّن”؟ لأنها بتعالج أكبر صداع عند المطورين:

• الخوف من التعديل: بتعطيك الشجاعة تعدل على الكود القديم (Refactoring) وتحسّنه بدون ما تخاف تكسر الدنيا.
• الثقة عند الإطلاق: بدل ما تكون قلقان وقت إطلاق الإصدار الجديد، بتكون متأكد إن كل الميزات الأساسية شغالة 100%.
• كشف الأخطاء مبكراً: بتكتشف المشاكل في مرحلة التطوير، مش بعد ما توصل للمستخدم النهائي ويصير الضرر كبير.

الكابوس اليدوي مقابل الحلم الآلي

طيب، كيف بنعمل هاي الاختبارات؟ عنا طريقتين، وحدة بتجيب الجلطة والتانية بتجيب الراحة.

الاختبار التراجعي اليدوي: طريق الجحيم المعبد بالنوايا الحسنة

في البداية، كنا نعمل هاي الاختبارات بشكل يدوي. كان عنا ملف Excel ضخم فيه قائمة بكل ميزات النظام، ومع كل تحديث، كان في موظف مسكين (أو أنا شخصياً في أوقات الزنقة) لازم يمر على هاي القائمة نقطة نقطة ويتأكد إنها شغالة.

المشاكل كانت واضحة:

• بطيء جداً: ممكن ياخد أيام لاختبار نظام متوسط الحجم.
• مكلف: وقت الموظفين هاد بفلوس.
• ممل وعرضة للخطأ: لما تكرر نفس الخطوات 100 مرة، أكيد رح “تزهق” وتفوّت خطوات أو ما تنتبه لبعض الأخطاء.
• غير قابل للتوسع: كل ما كبر النظام، صارت العملية شبه مستحيلة.

الاختبار التراجعي الآلي: رفيقك الأمين في كل إصدار

هنا يأتي دور الأتمتة. بدل ما إنسان يضغط على الأزرار ويكتب في الحقول، بنكتب “سكربت” أو “كود” برمجي يقوم بنفس هاي المهمة. هذا السكربت (الاختبار الآلي) بيقدر يشتغل بسرعة خيالية، ويعيد نفسه آلاف المرات بدون أي خطأ أو ملل.

الجميل في الموضوع إنه ممكن ندمج هاي الاختبارات مع عملية التطوير نفسها (ما يعرف بالـ CI/CD)، بحيث تشتغل تلقائياً مع كل تغيير في الكود. لو أي اختبار فشل، العملية كلها بتوقف، والمبرمج بيوصله تنبيه فوري عشان يصلح المشكلة قبل ما تكبر.

كيف نبدأ رحلة الأتمتة؟ (دليل أبو عمر العملي)

حكيت كتير تنظير، هلأ إجا وقت الشغل الصح. كيف تبدأ فعلياً بكتابة هاي الاختبارات؟

الخطوة الأولى: اختيار الأدوات المناسبة (العدة الصح للشغل الصح)

ما في أداة واحدة هي الأفضل للكل، اختيارك بيعتمد على تقنيات مشروعك. هاي أشهر الأدوات اللي بنصح فيها:

• لاختبار واجهات الويب (Web UI):
  • Playwright: خياري المفضل حالياً. أداة حديثة من مايكروسوفت، سريعة جداً، سهلة الكتابة، وتدعم كل المتصفحات الرئيسية.
  • Cypress: مشهورة جداً وسهلة للمبتدئين، بيئتها متكاملة ورائعة لتصحيح الأخطاء.
  • Selenium: الأداة “الختيارة” في هذا المجال. قوية جداً وتدعم لغات برمجة كثيرة، بس ممكن تكون أصعب شوي في الإعداد من غيرها.
• لاختبار الواجهات البرمجية (API Testing):
  • Postman/Newman: بتقدر تبني مجموعة اختبارات كاملة لواجهات ה-API باستخدام واجهة Postman الرسومية، وبعدين تشغلها من سطر الأوامر باستخدام Newman عشان تدمجها في الـ CI/CD.
  • REST Assured: مكتبة ممتازة لمشاريع Java، بتخلي كتابة اختبارات ה-API سهلة ومقروءة.

الخطوة الثانية: كتابة أول اختبار تراجعي آلي (يلا نكتب كود!)

خلينا ناخد مثال عملي. بدنا نكتب اختبار آلي يتأكد إنه ميزة تسجيل الدخول (Login) في موقعنا شغالة تمام. رح أستخدم Playwright مع TypeScript لأنه بسيط وواضح.

أولاً، تأكد من تثبيت Playwright في مشروعك:

npm init playwright@latest

الآن، لنكتب الاختبار في ملف اسمه `login.spec.ts`:

import { test, expect } from '@playwright/test';

// نُعرّف مجموعة اختبارات خاصة بصفحة تسجيل الدخول
test.describe('Login Functionality', () => {

  // هذا هو الاختبار الأول: التأكد من نجاح تسجيل الدخول ببيانات صحيحة
  test('should allow a user to log in with valid credentials', async ({ page }) => {
    
    // 1. الانتقال إلى صفحة تسجيل الدخول
    await page.goto('https://your-app.com/login');

    // 2. إيجاد حقل البريد الإلكتروني وتعبئته
    //    نستخدم محددات واضحة مثل الـ "data-testid" لتجنب كسر الاختبار مع تغيير التصميم
    await page.getByTestId('email-input').fill('testuser@example.com');

    // 3. إيجاد حقل كلمة المرور وتعبئته
    await page.getByTestId('password-input').fill('ValidPassword123');

    // 4. الضغط على زر تسجيل الدخول
    await page.getByTestId('login-button').click();

    // 5. التحقق (Assertion): نتوقع أن يتم توجيه المستخدم إلى لوحة التحكم
    //    وأن تحتوي الصفحة على رسالة ترحيب.
    //    هذا هو أهم جزء، هنا نتأكد أن الاختبار نجح.
    await expect(page).toHaveURL('https://your-app.com/dashboard');
    await expect(page.getByText('مرحباً بك، يا مستخدم!')).toBeVisible();
  });

  // ممكن نضيف اختبار تاني: التأكد من فشل تسجيل الدخول ببيانات خاطئة
  test('should show an error message with invalid credentials', async ({ page }) => {
    await page.goto('https://your-app.com/login');
    await page.getByTestId('email-input').fill('wrong-user@example.com');
    await page.getByTestId('password-input').fill('WrongPassword');
    await page.getByTestId('login-button').click();

    // التحقق: نتوقع ظهور رسالة خطأ
    await expect(page.getByText('البريد الإلكتروني أو كلمة المرور غير صحيحة')).toBeVisible();
  });
});

هذا الكود البسيط صار الحارس الأمين لميزة تسجيل الدخول. في كل مرة يتم فيها تشغيل هذا الاختبار، سيقوم بكل هذه الخطوات ويتأكد أن كل شيء يعمل كما هو متوقع. لو فشل أي جزء، سيعلمك فوراً.

الخطوة الثالثة: تحديد ما يجب اختباره (مش كل إشي بنعمله آلي!)

من الأخطاء الشائعة محاولة أتمتة 100% من كل شيء. هذا غير عملي ومضيعة للوقت. ركز على ما يهم حقاً حسب الأولوية:

1. الأولوية القصوى (The Critical Path): المسارات الأساسية اللي بيستخدمها معظم المستخدمين. مثل: تسجيل مستخدم جديد، تسجيل الدخول، البحث عن منتج، إضافة للسلة، عملية الدفع. هذه يجب أن تكون مؤتمتة 100%.
2. الأولوية المتوسطة: الميزات الهامة ولكنها ليست حرجة، أو الميزات التي تتأثر بالتحديثات بشكل متكرر. مثل: تعديل الملف الشخصي، كتابة مراجعة لمنتج.
3. الأولوية المنخفضة: الميزات الثانوية جداً أو حالات الاستخدام النادرة (Edge cases). هذه يمكن تركها للاختبار اليدوي إذا لزم الأمر.

نصيحة من أبو عمر: ابدأ صغيراً. أتمتة مسار واحد حرج (مثل تسجيل الدخول) أفضل من عدم وجود أي أتمتة على الإطلاق. مع الوقت، قم بزيادة تغطية الاختبارات تدريجياً.

ربط الاختبارات بالـ CI/CD: الأتمتة في أبهى صورها

القوة الحقيقية للاختبارات الآلية تظهر عند دمجها في خط أنابيب التكامل والنشر المستمر (CI/CD Pipeline). الفكرة هي أن هذه الاختبارات تعمل تلقائياً في كل مرة يقوم فيها مطور بدفع كود جديد إلى المستودع (مثل GitHub أو GitLab).

هذا مثال بسيط جداً لكيفية إعداد ذلك في GitHub Actions (ملف باسم .github/workflows/ci.yml):

name: CI Pipeline

on: [push]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm install

      # تثبيت متصفحات Playwright اللازمة
      - name: Install Playwright Browsers
        run: npx playwright install --with-deps

      # أهم خطوة: تشغيل الاختبارات التراجعية
      - name: Run Playwright tests
        run: npx playwright test

      # الخطوة التالية (مثل النشر) لن تعمل إذا فشلت الاختبارات
      # - name: Deploy to production
      #   if: github.ref == 'refs/heads/main' && success()
      #   run: ...

بهذه الطريقة، أنشأت “حارس بوابة” آلي. لا يمكن لأي كود “مكسور” أن يصل إلى مرحلة النشر، لأن الاختبارات ستكشفه وتوقف العملية كلها. هذا هو الأمان الحقيقي!

نصائح من خبرة أبو عمر (خلاصة السنين)

• اجعل اختباراتك مستقلة: كل اختبار يجب أن يعمل بمعزل عن الآخر. لا تجعل اختبار “حذف منتج” يعتمد على نجاح اختبار “إضافة منتج”. قم بإعداد الحالة التي يحتاجها كل اختبار على حدة.
• استخدم محددات اختبار مستقرة (Stable Selectors): تجنب استخدام محددات CSS أو XPath معقدة قد تتغير مع أي تعديل بسيط في التصميم. الأفضل هو أن تطلب من فريق الواجهة الأمامية إضافة معرفات فريدة مخصصة للاختبار مثل data-testid="login-button".
• لا تجعل الاختبارات تعتمد على نصوص قد تتغير: إذا كنت تختبر تطبيق متعدد اللغات، لا تتحقق من وجود نص “Login”. بدلاً من ذلك، تحقق من وجود العنصر نفسه عبر معرفه الفريد.
• الاختبارات هي جزء من الكود: عامل ملفات الاختبارات بنفس أهمية كود التطبيق. ضعها في نظام التحكم بالإصدارات (Git)، واعمل لها مراجعة (Code Review)، وقم بتحسينها باستمرار.

– حافظ على سرعة الاختبارات: كلما كانت أسرع، كانت حلقة التغذية الراجعة للمطور أسرع. ابحث دائماً عن طرق لتحسين أداء مجموعة الاختبارات.

الخلاصة 🏁

يا أصدقائي المبرمجين والمبرمجات، الاستثمار في الاختبارات التراجعية الآلية ليس رفاهية، بل هو أساس الهندسة البرمجية الاحترافية. هو الحاجز الذي يفصل بين بيئة العمل الفوضوية المليئة بالخوف، وبيئة العمل المنظمة التي تمنحك الثقة لإطلاق إبداعك وتحسين منتجك باستمرار.

قد تبدو البداية صعبة، ولكن الفائدة على المدى الطويل لا تقدر بثمن. ستحول الخوف من كبسة “Deploy” إلى لحظة من الثقة والاحتفال. ابدأ اليوم، ولو باختبار واحد بسيط، وستشكرني لاحقاً.

استثمر في جودة كودك اليوم، عشان ترتاح وتنام مرتاح بكرة. ويلا، شدوا حيلكم! ✅