لماذا تتحدث Maison Code عن هذا

في Maison Code Paris، نعمل كضمير معمari لعملائنا. غالبًا ما نرث حزمًا “حديثة” تم بناؤها دون فهم أساسي للحجم.

نناقش هذا الموضوع لأنه يمثل نقطة تحول حاسمة في النضج الهندسي. التنفيذ الصحيح يميز MVP الهش عن منصة مؤسسية مرنة يمكنها التعامل مع حركة مرور الجمعة السوداء.

الخوف من النشر

كل مهندس برمجيات يعرف هذا الشعور. إنه يوم الجمعة، الساعة 4:00 مساءً. لقد قمت للتو بدمج طلب السحب. يتحول مسار النشر إلى اللون الأخضر. يجب أن تكون سعيدا. لكنك تتعرق. “هل قمت بكسر تدفق الخروج؟” “هل قمت بكسر إعادة تعيين كلمة المرور؟” “هل قمت باختبار قائمة الهاتف المحمول في Safari؟” إذا كنت تعتمد على الاختبار اليدوي (النقر فوق الموقع بنفسك)، فأنت تعيش في حالة خوف دائمة. البشر فظيعون في اختبار الانحدار. نشعر بالملل. نحن نفتقد الأشياء. نحن نختبر “الطريق السعيد” وننسى حالات الحافة. مع نمو قاعدة التعليمات البرمجية، يزداد الوقت اللازم لاختبارها يدويًا بشكل خطي. في النهاية، ستتوقف عن الاختبار. وذلك عندما تتسرب الأخطاء إلى الإنتاج. وعندما تتسرب الأخطاء، تفقد الإيرادات. تفقد الثقة. الاختبار الآلي هو العلاج لهذا الخوف. إنه يحول النشر من “حدث عالي الخطورة” إلى “ليس حدثًا”.

لماذا تناقش Maison Code الاختبار الآلي

في Maison Code، نعمل مع العلامات التجارية الفاخرة عالية المخاطر ومنصات التجارة الإلكترونية ذات الحركة الكثيفة. يحقق عملاؤنا آلاف اليورو في الدقيقة خلال ذروة المبيعات (الجمعة السوداء، عيد الميلاد). لا يمثل الخطأ “البسيط” في عملية الدفع أي إزعاج؛ إنها كارثة مالية. لقد رأينا العلامات التجارية تخسر 50 ألف دولار في ساعة واحدة بسبب تغطية زر “AddToCart” بخطأ Z-Index على iPhone 12. نحن نتحدث عن الاختبار الآلي لأن الاستقرار هو الإيرادات. نحن لا نبيع “الكود”. نبيع “الموثوقية”. غالبًا ما يكون تنفيذ مجموعة E2E القوية هو أول شيء نقوم به عند تدقيق قاعدة التعليمات البرمجية القديمة للعميل. إنه يوقف النزيف ويسمح لنا بإعادة البناء بثقة.

1. هرم الاختبار: الإطار الاستراتيجي

قام مايك كوهن بنشر مفهوم “هرم الاختبار”، ولا يزال المعيار الذهبي لاستراتيجية الاختبار. فهو يحدد التوزيع المثالي للاختبارات في جناحك.

1. اختبارات الوحدة (70%):

   • النطاق: الوظائف أو الفئات الفردية.
   • السرعة: ميلي ثانية.
   • التكلفة: رخيصة.
   • الأداة: الدعابة، فيتيست.
   • مثال: أضف(2, 2) === 4.

2. اختبارات التكامل (20%):

   • النطاق: التفاعلات بين المكونات (على سبيل المثال، تمرير الوالدين للدعائم إلى الطفل).
   • السرعة: ثانية.
   • التكلفة: متوسطة.
   • الأداة: مكتبة اختبار التفاعل.

3. الاختبارات الشاملة (E2E) (10%):

   • النطاق: يتدفق المستخدم بالكامل في متصفح حقيقي.
   • السرعة: دقيقة.
   • التكلفة: باهظة الثمن (حساب ثقيل).
   • الأداة: الكاتب المسرحي، السرو.

سنركز في هذه المقالة على قمة الهرم: اختبار E2E. لماذا؟ لأنه يوفر أعلى معامل الثقة. يمكن أن ينجح اختبار الوحدة حتى لو كان زر “إرسال” مخفيًا بسبب خطأ z-index في CSS. سوف يفشل اختبار E2E، لأنه يحاول النقر على الزر. إذا كان اختبار E2E يشير إلى “عنصر تم شراؤه بواسطة المستخدم”، فيمكنك التأكد بنسبة 99.9% من أنه يمكن للمستخدمين شراء العناصر.

2. أداة الاختيار: الكاتب المسرحي

لمدة عقد من الزمن، كان السيلينيوم هو المعيار. لقد كان بطيئًا، ومعتمدًا على Java، ومتقشرًا بشكل ملحوظ. ثم جاء ** السرو **. لقد كان تحسينًا هائلاً، مع تجربة رائعة للمطورين، ولكن كان به قيود معمارية (التشغيل داخل صندوق حماية المتصفح، ودعم محدود لعلامات التبويب المتعددة). اليوم، معيار الصناعة هو الكاتب المسرحي (من شركة Microsoft). لماذا الكاتب المسرحي؟

1. السرعة: تجري اختبارات بالتوازي عبر عمليات عاملة متعددة.
2. الموثوقية: تحتوي على ميزة “الانتظار التلقائي”. إنه ينتظر أن تكون العناصر قابلة للتنفيذ قبل التفاعل. لا مزيد من “النوم (1000)”.
3. متصفح متعدد: يتم اختباره محليًا على Chromium وFirefox وWebKit (Safari).
4. التتبع: يقوم بتسجيل فيديو كامل وتتبع DOM لكل فشل، مما يجعل تصحيح الأخطاء أمرًا تافهًا.

3. التنفيذ: اختبار تدفق الخروج

دعونا نلقي نظرة على مثال من العالم الحقيقي. نريد اختبار إمكانية قيام المستخدم الضيف بشراء منتج ما.

// الاختبارات/checkout.spec.ts
استيراد {اختبار، توقع} من '@playwright/test'؛

test.describe('تدفق الخروج', () => {
  
  // عزل بيئة الاختبار
  test.beforeEach(async ({page }) => {
    // إعادة تعيين ملفات تعريف الارتباط/التخزين
    انتظر page.context().clearCookies();
  });

  اختبار ("يمكن للمستخدم الضيف شراء عنصر"، غير متزامن ({صفحة }) => {
    // 1. التنقل
    console.log("الانتقال إلى صفحة المنتج...");
    في انتظار page.goto('/products/silk-shirt');
    انتظر توقع(صفحة).toHaveTitle(/قميص حريري/);
    
    // 2. أضف إلى سلة التسوق
    // استخدم محددات المواقع التي تواجه المستخدم (الدور، التسمية، النص)
    // تجنب محددات CSS مثل '.btn-primary' (الهشة)
    انتظر page.getByRole('button', { name: 'أضف إلى سلة التسوق' }).click();
    
    // 3. تحقق من درج العربة
    const cartDrawer = page.getByTestId('cart-drawer');
    انتظر توقع (cartDrawer).toBeVisible();
    في انتظار توقع(cartDrawer).toContainText('قميص حريري');
    
    // 4. انتقل إلى الخروج
    انتظر page.getByRole('link', { name: 'Checkout' }).click();
    انتظار توقع(صفحة).toHaveURL(/.*\/checkout/);
    
    // 5. املأ النموذج (الدفعة الساخرة)
    انتظر page.getByLabel('Email').fill('test-bot@maisoncode.paris');
    انتظر page.getByLabel('الاسم الأول').fill('اختبار');
    انتظر page.getByLabel('اسم العائلة').fill('Bot');
    انتظر page.getByLabel('Address').fill('123 شارع الاختبار');
    
    // 6. الدفع (مخطط وهمي)
    // في E2E الصارم، قد نستخدم بطاقة اختبار شريطية.
    انتظر page.getByLabel('رقم البطاقة').fill('4242 4242 4242 4242');
    انتظر page.getByLabel('انتهاء الصلاحية').fill('12/30');
    انتظر page.getByLabel('CVC').fill('123');
    
    // 7. إرسال
    انتظر page.getByRole('button', { name: 'ادفع الآن' }).click();
    
    // 8. تأكيد النجاح
    // زيادة المهلة لأن معالجة الدفع تستغرق وقتًا
    انتظر توقع(page.getByText('شكرًا لك على طلبك')).toBeVisible({ timeout: 15000 });
  });

});

4. التعامل مع “الهشاشة” (القاتل الصامت)

الاختبار غير المستقر هو اختبار ينجح في 90% من الوقت ويفشل في 10% من الوقت، دون أي تغييرات في التعليمات البرمجية. التقشر هو العدو. إذا توقف المطورون عن الثقة في الاختبارات (“أوه، فقط أعد تشغيلها، إنها غير مستقرة”)، تصبح مجموعة الاختبار عديمة الفائدة.

الأسباب الشائعة:

1. زمن استجابة الشبكة: تستغرق واجهة برمجة التطبيقات (API) 5.1 ثوانٍ عندما تكون المهلة 5 ثوانٍ.
2. الرسوم المتحركة: النقر على الزر أثناء انزلاقه للداخل.
3. تلوث البيانات: يحذف الاختبار (أ) المستخدم الذي يحتاجه الاختبار (ب).

الحلول:

1. الاستهزاء (اعتراض الشبكة): بدلاً من استدعاء واجهة برمجة تطبيقات Contentful الحقيقية (والتي قد تكون بطيئة)، اعترض الطلب وأعد JSON ثابتًا.

   في انتظار الصفحة.route('**/api/products', المسار => {
     ute.fulfill({ path: 'mock-data/products.json' });
   });

   وهذا يجعل الاختبار أسرع بـ 10 مرات وحتميًا بنسبة 100٪.
2. إعادة المحاولة: قم بتكوين CI لإعادة محاولة الاختبارات الفاشلة تلقائيًا. إعادة المحاولة: 2. إذا تمت إعادة المحاولة، فسيكون الأمر غير مستقر، لكنه على الأقل لا يمنع النشر.

5. اختبار الانحدار البصري (Pixel Perfect)

يتحقق الكاتب المسرحي من الوظيفة (“هل الزر قابل للنقر؟”). لا يتحقق من الجماليات (“هل الزر وردي؟”). إذا قمت بحذف main.css عن طريق الخطأ، فقد يظل Playwright ناجحًا (الزر قابل للنقر عليه، ولكنه غير مرئي فقط). ** اختبار الانحدار البصري ** (لقطات بيرسي / اللوني / الكاتب المسرحي) يعمل على إصلاح هذه المشكلة. في انتظار توقع(صفحة).toHaveScreenshot();

1. التقط لقطة شاشة للصفحة.
2. قارنها بـ “الصورة الذهبية” (خط الأساس).
3. إذا اختلفت وحدات البكسل بنسبة > 1%، فستفشل في الاختبار. يؤدي هذا إلى اكتشاف “انحدارات CSS” التي لا يمكن لأي اختبار وظيفي أن يتمكن منها على الإطلاق.

6. إجراءات GitHub: حارس البوابة الآلي

لا يمكنك إجراء اختبارات على الكمبيوتر المحمول الخاص بك. يمكنك تشغيلها على CI (التكامل المستمر). في كل مرة تقوم فيها بالدفع إلى GitHub، يتم تشغيل سير العمل.

“يامل

.github/workflows/e2e.yml

الاسم: الكاتب المسرحي E2E على: ادفع: الفروع: [الرئيسية] طلب سحب: الفروع: [الرئيسية]

وظائف: اختبار: دقائق المهلة: 60 يعمل على: أوبونتو الأحدث الخطوات: - الاستخدامات: الإجراءات/الخروج@v3 - الاستخدامات: action/setup-node@v3 مع: نسخة العقدة: 18 - الاسم: تثبيت Deps تشغيل: npm ci - الاسم: تثبيت المتصفحات تشغيل: تثبيت الكاتب المسرحي npx —with-deps

  - الاسم : تشغيل الكاتب المسرحي
    تشغيل: اختبار الكاتب المسرحي npx
    البيئة:
      سي آي: صحيح
      BASE_URL: ${{ github.event.deployment.payload.web_url }} // اختبر عنوان URL لمعاينة Vercel

  - الاسم: رفع التقرير
    الاستخدامات: action/upload-artifact@v3
    إذا: دائمًا ()
    مع:
      الاسم: تقرير مسرحي
      المسار: تقرير الكاتب المسرحي/

## 7. تكلفة CI (التحسين)

يعد إجراء 500 اختبار E2E على كل التزام أمرًا مكلفًا (دقائق إجراءات GitHub).
**استراتيجيات التحسين**:
1. **التقسيم**: تقسيم الاختبارات عبر 10 أجهزة مما يجعلها تعمل بشكل أسرع 10 مرات.
`اختبار الكاتب المسرحي npx --shard=1/10`.
2. **المشاريع المتأثرة فقط**: استخدم **Nx** أو **Turbo** لتشغيل الاختبارات للتطبيقات التي تم تغييرها فقط.
3. **اختبارات الدخان للممثلين الرئيسيين**: قم بتشغيل مجموعة فرعية صغيرة (المسار الحرج) على المستفيدين الرئيسيين. قم بتشغيل المجموعة الكاملة على Main.

## 8. الاستنتاج

الاختبار الآلي ليس "عملاً إضافيًا". إنه **العمل**.
هذا هو الفرق بين النموذج الأولي والمنتج.
هذا هو الفرق بين "آمل أن ينجح" و"أعلم أنه يعمل".
ابدأ اليوم. اكتب اختبارًا واحدًا. اختبار تسجيل الدخول.
ثم اختبار الخروج.
قريبا، سوف تنام بشكل أفضل في الليل.


<hr style="margin: 1rem 0" />

### الإصدارات التي تسبب الذعر؟
لقد قمنا بتصميم مجموعات اختبار E2E الآلية باستخدام Playwright التي تكتشف الأخطاء قبل المستخدمين.


**[أتمتة ضمان الجودة الخاص بي](/services/tech)**.
**[قم بتوظيف مهندسينا](/contact)**.