اختبار المنطق التجاري المرئي: ماذا تؤتمت أولًا

ما الذي ينهار عادةً في المنطق التجاري المرئي

تبدو سير العمل المرئية أكثر أمانًا لأنك ترى المنطق. لكنها مع ذلك تتغير كثيرًا، وتعديلات بسيطة قد تكسر مسارات المستخدم الحقيقية. لهذا السبب يهم اختبار المنطق التجاري المرئي حتى في أدوات الـ no-code.

ما ينهار في الغالب ليس "الفكرة الكبيرة" لسير العمل. بل الاتصالات الصغيرة: تغير عامل شرط (مثلاً «و» مقابل «أو»)، تغيير قيمة افتراضية، تنفيذ خطوة بترتيب خاطئ، أو تخطي فرع خطأ. في AppMaster، سترى هذا عندما يُحرر Business Process، يُعاد تسمية حقل في Data Designer، أو يتطور شكل استجابة API.

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

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

طريقة عملية للتفكير في التغطية هي ثلاث طبقات تدعم بعضها البعض:

• اختبارات على مستوى سير العمل تشغّل المسارات الرئيسية من البداية إلى النهاية (إرسال الطلب -> التحقق -> الموافقة -> الإشعار).
• فحوص عقود API التي تؤكد أن المدخلات والمخرجات لا تزال تطابق ما تتوقعه الواجهة والتكاملات.
• بيانات اختبار قابلة لإعادة الإنشاء يمكن بناؤها بنفس الطريقة حتى بعد تغيّر النماذج.

مثال: إذا كان لدى تطبيق دعم إجراء "موافقة استرداد"، فلا تحتاج لاختبار كل شاشة. تحتاج ثقة بأن الطلبات فوق حد معين تُوجّه دائمًا إلى مدير، وأن الحالة تتحدث بشكل صحيح، وأن الرسالة المرسلة عبر البريد أو Telegram تتضمن الحقول الصحيحة.

خريطة اختبار بسيطة لسير العمل وAPIs وواجهة المستخدم

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

الاختبارات "على غرار الوحدة" تركز على قاعدة واحدة في كل مرة: حساب، شرط، تغيير حالة. هي سريعة وتحدد موقع العطل، لكنها تفوّت المشاكل التي تظهر فقط عندما تتسلسل خطوات متعددة معًا.

اختبارات مستوى سير العمل هي الطبقة المتوسطة. تبدأ بحالة واضحة، تدفع مدخلاً واقعيًا عبر سير العمل، وتؤكد النتائج المهمة (سجلات منشأة، حالات متغيرة، إشعارات مرسلة، أفعال مرفوضة). في AppMaster، غالبًا ما يعني ذلك تشغيل Business Process من البداية إلى النهاية دون النقر عبر كل واجهة.

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

عندما تختار أصغر شريحة موثوقة للاختبار، هذا الترتيب يعمل جيدًا:

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

لمعالجة عملية الموافقة، قد يعني ذلك: اختبار سير عمل واحد ينقل الطلب من Draft إلى Approved، فحص عقد واحد للحفاظ على حقل status متوافقًا، واختبار واجهة يثبت أن المستخدم يمكنه تقديم طلب.

ماذا تؤتمت أولًا (وماذا تترك يدويًا الآن)

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

بعد ذلك، استهدف سير العمل المعقّد عمدًا: خطوات متعددة، فروع، محاولات إعادة، وتكاملات خارجية. شرط مفقود في مسار "الطريق السعيد" قد يصبح حادثًا حقيقيًا عندما يكون أحد الـ API بطيئًا، يتم رفض دفعة، أو للمستخدم دور غير اعتيادي.

التكرار مهم أيضًا. سير عمل يعمل آلاف المرات يوميًا (إنشاء طلب، توجيه تذكرة، إعادة تعيين كلمة المرور) يستحق الأتمتة قبل عملية إدارية تُنفّذ مرة في الشهر.

قبل كتابة اختبار، اجعل النتيجة قابلة للقياس. اختبار آلي جيد ليس "يبدو صحيحًا"، بل "السجل X ينتهي في الحالة Y، وهذه الآثار الجانبية حدثت مرة واحدة تمامًا." بالنسبة لـ AppMaster Business Processes، يترجم ذلك بوضوح إلى المدخلات، تغيّرات الحالة المتوقعة، والاستدعاءات أو الرسائل المتوقعة.

فلتر سريع لما تؤتمت أولًا:

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

اترك الاختبارات اليدوية للفحوص الاستكشافية، التخطيط المرئي، وحالات الحافة التي ما تزال تكتشفها. أتمت عندما يستقر السلوك ويتفق الجميع على معنى "النجاح".

اختبارات مستوى سير العمل التي تلتقط أعطالًا منطقية حقيقية

تقع اختبارات مستوى سير العمل خطوة واحدة فوق اختبارات الوحدة. تعتبر سير العمل صندوقًا أسود: شغّله ثم تحقّق من الحالة النهائية والآثار الجانبية. هنا تلتقط الأعطال التي يشعر بها المستخدمون فعليًا.

ابدأ بتسمية مشغل واحد ونتيجة واحدة مهمة. مثلاً: "عند تقديم طلب، تصبح الحالة Pending ويُخطر الموافق." إذا ظل ذلك صحيحًا، فعادةً ما لا تهم عمليات إعادة الهيكلة الداخلية الصغيرة.

غطِّ الفروع التي تغير النتائج، لا كل عقدة. مجموعة مدمجة تكون:

• مسار النجاح (كل شيء صالح، المستخدم مسموح)
• فشل التحقق (حقل مفقود، صيغة خاطئة، مبلغ خارج النطاق)
• رفض الأذونات (المستخدم يمكنه العرض لكن لا يمكنه الفعل)

ثم تحقّق الآثار الجانبية التي تثبت أن سير العمل نفّذ فعلاً: سجلات منشأة أو محدثة في PostgreSQL، حقول الحالة المتغيرة، والرسائل المرسلة (بريد/SMS أو Telegram) إذا كنت تستخدم تلك الوحدات.

نمط يبقي الاختبارات قصيرة هو "شغّل، ثم أكد النتائج":

• المشغل: أنشئ الحد الأدنى من المدخلات وابدأ سير العمل (نداء API، حدث، أو إجراء زر)
• الحالة النهائية: الحالة، المالك/المكلَّف، الطوابع الزمنية
• الآثار الجانبية: سجلات جديدة، سجلات تدقيق، إشعارات مضافة إلى الطابور
• قواعد العمل: حدود، موافقات مطلوبة، "لا يمكنك الموافقة على طلبك بنفسك"
• لا مفاجآت: لا شيء إضافي مُنشأ، ولا رسائل مكررة

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

اجعل كل اختبار سير عمل مركزًا على نتيجة واحدة. إذا حاول الاختبار التحقق من خمسة قواعد وثلاثة آثار جانبية، سيصبح صعب القراءة ومؤلم الإصلاح.

فحوص عقود API التي تمنع تغييرات كاسرة صامتة

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

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

ما الذي يجب تثبيته في العقد

ابدأ بما يكسر العملاء بهدوء:

• أكواد الحالة للحالات الشائعة (نجاح، خطأ تحقق، مرفوض، غير موجود)
• الحقول المطلوبة في الطلبات والاستجابات (وأيها يمكن أن يكون null)
• أنواع الحقول والصيغ (رقم مقابل نص، صيغة التاريخ، قيم enum)
• رسائل التحقق (مفاتيح/أكواد مستقرة، لا نص دقيق)
• شكل الخطأ (أين يكون الخطأ، وكيف تُعاد الأخطاء المتعددة)

ضمن حالات سلبية عمدًا: إرسال طلب بلا حقل مطلوب، إرسال نوع خاطئ، أو محاولة فعل دون إذن. هذه الاختبارات رخيصة وتكشف افتراضات غير متطابقة بين سير العمل وAPI.

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

أين تشغّل فحوص العقود

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

• CI على كل تغيير للنهايات الأساسية
• استيج بعد النشر لاكتشاف مشاكل متعلقة بالبيئة
• تشغيلات ليلية لتغطية واسعة دون إبطاء الفريق

اتفق على توقعات التوافق أيضًا. إذا كان يجب أن تعمل العملاء القدامى، عامل إزالة الحقول أو تغيير المعاني كإصدار جديد وليس كـ "إعادة هيكلة صغيرة".

بيانات اختبار قابلة لإعادة الإنشاء يمكنك الوثوق بها

اختبارات سير العمل مفيدة فقط إذا بدأت من نفس النقطة في كل مرة. بيانات الاختبار القابلة لإعادة الإنشاء متوقعة، معزولة عن اختبارات أخرى، وسهلة إعادة التهيئة حتى لا تؤثر نتيجة أمس على نتيجة اليوم. هنا يفشل كثير من جهود الاختبار بهدوء.

احتفظ بمجموعة بذور صغيرة تغطي الأدوار والسجلات الأساسية التي تعتمد عليها سير العمل: مستخدم Admin، مدير، موظف عادي، عميل واحد، اشتراك نشط واحد، وسجل «حالة مشكلة» واحد (مثل فاتورة متأخرة). أعد استخدام هذه البذور عبر الاختبارات حتى تقضي وقتك في التحقق من المنطق وليس اختراع بيانات.

قبل إضافة المزيد من الاختبارات، قرر كيف تعود البيئة إلى حالة نظيفة:

• إعادة بناء بيئة الاختبار من الصفر في كل تشغيل (بطيء، نظيف جدًا)
• اقتطاع أو مسح الجداول الأساسية بين التشغيلات (سريع، يحتاج حذر)
• إعادة إنشاء ما يتعامل معه كل اختبار فقط (الأسرع، الأسهل للخطأ)

تجنّب العشوائية للفحوص الأساسية. الأسماء العشوائية، الطوابع الزمنية، والمبالغ مناسبة للتشغيلات الاستكشافية، لكنها تجعل المقارنة بين النجاح/الفشل صعبة. إذا احتجت تنوعًا، استخدم قيمًا ثابتة (مثل InvoiceTotal = 100.00) وغيّر متغيرًا واحدًا فقط عندما يثبت الاختبار قاعدة معينة.

اكتب أيضًا الحد الأدنى من البيانات المطلوبة لكل اختبار سير عمل: أي دور مستخدم، أي حقول حالة، وأي كيانات مرتبطة يجب أن توجد قبل بدء Business Process. عندما يفشل اختبار، ستعرف بسرعة ما إذا كان المنطق قد كسر أم أن الإعداد فشل.

جعل الاختبارات تصمد أمام تغييرات النماذج

تغييرات النماذج هي السبب رقم واحد وراء فشل الاختبارات الجيدة فجأة. تعيد تسمية حقل، تقسم جدولًا واحدًا إلى اثنين، تغير علاقة، أو تعيد توليد تطبيق AppMaster بعد تحديث Data Designer، وسيحاول إعداد الاختبار الكتابة بشكل قديم. الأسوأ أن الاختبارات قد تمر بينما تتحقق من الشيء الخطأ إذا اعتمدت على معرفات داخلية هشة.

ترميز معرفات قاعدة البيانات أو UUIDs المُولَّدة تلقائيًا يقع كثيرًا في المصيدة. هذه القيم لا تحمل معنى عمل ويمكن أن تتغير عند إعادة تهيئة البيانات، إعادة بناء البيئات، أو إضافة كيانات جديدة. اربط الاختبارات بمعرّفات عمل ثابتة مثل البريد الإلكتروني، رقم الطلب، المرجع الخارجي، أو كود مقروء بشريًا.

ابنِ بيانات الاختبار من النموذج الحالي

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

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

قواعد تبقي المجموعات مستقرة:

• استخدم مفاتيح عمل في التأكيدات (مثل employee_email)، لا معرفات داخلية.
• مركزيّة إنشاء الكيانات في منشئين (مكان واحد للتحديث عند تغير الحقول).
• احتفظ بـ 5–10 سجلات قانونية تغطي معظم سير العمل.
• أضف اختبار تحقق من الهجرة يضمن أن بيانات البذور لا تزال تُحمّل.
• فشل سريع عندما تتغير الحقول أو العلاقات المطلوبة (بمخرجات خطأ واضحة).

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

أين تحتاج مشاريع AppMaster اهتمامًا إضافيًا

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

عند تحرير Data Designer (نموذج PostgreSQL)، افترض أن بيانات البذور القديمة قد لا تناسب بعد الآن. حقل أعيد تسميته، عمود مطلوب جديد، أو علاقة تغيّرت قد تكسر سكربتات الإعداد وتجعل الاختبارات تفشل لسبب خاطئ. استخدم كل تحديث لنموذج البيانات كفرصة لتحديث بيانات البذور بحيث تبدأ الاختبارات من أساس نظيف وواقعي.

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

بالنسبة للـ APIs، اربط تغييرات النهايات بلقطات العقود. إذا تغيّرت المدخلات أو المخرجات، حدّث فحوص العقود في نفس جلسة العمل حتى لا تُطلق تغييرًا كاسرًا صامتًا إلى الويب أو المحمول.

في كل بيئة اختبار، تحقق مزدوجًا من:

• قواعد المصادقة والأدوار (خاصة إذا استخدمت مصادقة مضمّنة)
• الوحدات المفعلة (مدفوعات مثل Stripe، رسائل مثل Telegram/البريد/SMS)
• إعدادات التكامل والسرّية، أو استخدام دمى اختبار واضحة
• افتراضات النشر (Cloud vs self-hosted) التي تؤثر على التهيئة

مثال: تضيف حقل Department مطلوبًا وتعدّل خطوة BP لتوجيه الموافقات تلقائيًا. حدّث المستخدمين في بيانات البذور مع حقول الأقسام، ثم حدّث اختبار سير العمل للموافقة لتؤكد التوجيه الجديد. يعيد AppMaster توليد كود مصدر نظيف، مما يساعد في تقليل الانحراف، لكن فقط إذا كانت اختباراتك تستهدف السلوك (المخرجات، الحالات، الأذونات) بدلًا من تفاصيل التنفيذ.

خطة خطوة بخطوة لإعداد أول مجموعة اختبارات موثوقة

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

اكتب قائمة قصيرة من سير العمل الحرجة وحدّد النتيجة بكلمات بسيطة. "فاتورة موافق عليها من مدير تُنشئ طلب دفع" قابلة للاختبار. "الموافقة تعمل" ليست كذلك.

أنشئ مجموعة بذور بيانات دنيا لكل سير عمل. اجعلها صغيرة ومُسماة لسهولة التعرف في السجلات: مستخدم واحد لكل دور، حساب واحد، وثيقة واحدة لكل حالة. في AppMaster، مواءمة ذلك مع نموذج Data Designer تبقي البيانات متسقة مع تطور الحقول.

أتمت فقط التدفقات القليلة العليا كاملة على مستوى سير العمل. على سبيل المثال، ابدأ سريان الموافقة، قم بمحاكاة قرار المدير، وتحقق من الحالة النهائية (موافق، سجل تدقيق مُنشأ، إشعار مُرسل).

أضف فحوص عقود API فقط للنهايات التي تعتمد عليها تلك التدفقات. هدفك ليس اختبار كل شيء، بل التقاط تغييرات الشكل التي قد تكسر سير العمل بهدوء.

اجعل التشغيلات قابلة لإعادة:

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

هذا يحافظ على المجموعة صغيرة، سريعة، ومفيدة بينما ينمو المنطق المرئي.

أخطاء شائعة تجعل اختبارات سير العمل هشة

الاختبارات الهشة أسوأ من لا اختبارات. تعلّم الفرق تجاهل الفشل، وتنفلت الأعطال الحقيقية. السبب الأكبر هو معاملة سير العمل كسيناريو واجهة بدلًا من نظام أعمال.

الإفراط في أتمتة النقرات فخ كلاسيكي. إذا أثبت اختبارك أن زرًا يمكن النقر عليه، فهذا لا يثبت أن النتيجة الصحيحة حدثت. فحص أفضل هو: هل أنشأ سير العمل السجلات الصحيحة، وضع الحالات الصحيحة، وأرسل الرسالة الصحيحة. مع AppMaster، هذا عادةً يعني التحقق مما أنتجته Business Process (الحقول، الانتقالات، الآثار الجانبية)، لا كيفية التنقّل في الصفحة.

مصدر آخر للهشة هو حسابات اختبار مشتركة فوضوية. الفرق يعيد استخدام "مستخدم اختبار" حتى يملأ بمئات الطلبات القديمة، أذونات غريبة، ومسودات متبقية. ثم يفشل التشغيل الجديد أحيانًا فقط. فضّل مستخدمين جدد لكل تشغيل أو أعد ضبط مجموعة بيانات صغيرة إلى حالة معروفة.

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

أنماط تستحق الإصلاح مبكرًا:

• اختبار المسار السعيد فقط، فتُترك أخطاء الأذونات والحالات المرفوضة دون اختبار
• استخدام خطوات الواجهة لإثبات المنطق بدلًا من فحص نتائج سير العمل وسجل التدقيق
• الاعتماد على خدمات خارجية حية (مدفوعات، بريد/SMS) دون استبدال أو دمى اختبار
• مشاركة حسابات اختبار طويلة العمر التي تلوثت تدريجيًا
• ترميز معرفات أو افتراض الترتيبات والطوابع الزمنية

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

قائمة فحص سريعة قبل إضافة اختبارات جديدة

قبل أن تضيف اختبارًا آخر، تأكد أنه سيعوّض التكاليف. أسرع طريقة لتضخيم مجموعة تُهملها الجميع هي إضافة اختبارات صعبة القراءة، يصعب إعادة تشغيلها، ويسهل كسرها.

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

قائمة فحص قبل الإقلاع:

• هل يمكنك وصف النتيجة المتوقعة بجملة واحدة (مثال: "طلب معتمد ينشئ فاتورة ويخطر المالية")؟
• هل يمكنك إعادة ضبط البيانات وإعادة تشغيل الاختبار ثلاث مرات بنفس النتيجة؟
• لكل سير عمل حاسم، هل لديك حالة سلبية واحدة على الأقل (حقل مطلوب مفقود، دور خاطئ، حد مُجاوز) يجب أن تفشل بطريقة محددة؟
• إذا لمس سير العمل API، هل تتحقق من العقد (حقول مطلوبة، أنواع البيانات، شكل الخطأ)، لا مجرد "200 OK"؟
• إذا تغير نموذج البيانات، هل ستحدث الاختبار في أماكن مشتركة (builders/fixtures) أم ستبحث عبر قيمٍ مشفّرة؟

إذا كنت تبني في AppMaster، فضّل خطوات إعداد قابلة لإعادة الاستخدام التي تنشئ سجلات الاختبار عبر نفس API أو Business Process الذي يستخدمه تطبيقك. هذا يبقي الاختبارات أقرب إلى السلوك الحقيقي ويقلل الكسر عند تطور النموذج.

مثال: اختبار سير موافقة دون الإفراط

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

ابدأ باختبار فقط الأفعال التي تهم:

• الموافقة: يغيّر الموافق الحالة من "Pending" إلى "Approved" وتُضبط حقول التدقيق (من، متى).
• الرفض: يمكن للموافق تغييرها إلى "Rejected" ويتطلب سببًا.
• طلب التعديلات: يمكن للموافق تغييرها إلى "Needs changes" ويمكن لمقدم الطلب إعادة الإرسال.

أضف فحص عقد API حول نقطة النهاية الخاصة بالموافقة لأن هنا تكمن الأعطال الصامتة. على سبيل المثال، إذا كان سير العمل يستدعي POST /requests/{id}/approve، فتحقق من:

• كود الاستجابة (200 للنجاح، 403 للدور الخاطئ)
• شكل الاستجابة (الحقل status بقيمة معروفة، ووجود updated_at)
• قاعدة أساسية (لا يمكن أن تقفز الحالة من "Draft" مباشرةً إلى "Approved")

حافظ على بيانات الاختبار صغيرة وقابلة لإعادة التشغيل. قم بزرع ما يحتاجه المنطق فقط: مقدم طلب واحد، مقبول واحد، وطلب واحد في "Pending". معرّفات ثابتة (مثل إيميلات ثابتة) تسهل إيجاد نفس السجلات بعد إعادة التوليد.

تخيل تغيير نموذج: تضيف حقلًا مطلوبًا جديدًا مثل cost_center. تنهار كثير من المجموعات لأن الاختبارات تنشئ طلبات بالشكل القديم.

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

خطوات تالية: احفظ المجموعة صغيرة ومفيدة ومُحدّثة

تساعدك مجموعة الاختبارات فقط إذا وثق بها الفريق. الثقة تختفي عندما تنمو المجموعة بسرعة ثم تتعفن. ركز على مجموعة صغيرة من سير العمل التي تمثل قيمة عمل حقيقية.

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

إيقاع بسيط مناسب لمعظم الفرق:

• احتفظ بـ 5 إلى 10 اختبارات سير عمل عالية القيمة تعمل على كل تغيير.
• قم بتنظيف شهري لحذف الاختبارات الميتة وتحديث بيانات البذور.
• عندما يصل خطأ إلى الإنتاج، أضف اختبارًا كان سيلتقطه.
• اجعل بيانات الاختبار صغيرة ومُسماة حتى تكون الأخطاء سهلة الفهم.
• راجع الفشلات أسبوعيًا وأصلح الاختبار أو سير العمل فورًا.

التنظيف عمل حقيقي. إذا تغيّر سير العمل ولم يعد الاختبار يمثل الواقع، احذفه أو أعد كتابته فورًا.

إذا كنت تبني سير العمل وAPIs في AppMaster (appmaster.io)، يمكنك استخدام نفس الرؤى لتعريف نتائج ملموسة وربط مجموعة صغيرة من فحوص مستوى سير العمل مبكرًا. هذا غالبًا أبسط طريقة للحفاظ على التوافق مع تطور نموذج بياناتك.