كيف تبني سجلات اختبار اصطناعية لسير عمل
أنشئ مجموعة صغيرة من السجلات المُختلَقة، ربما من عشرة إلى عشرين، تتضمن عمدًا الحالة العادية والحالات الحدّية المحرجة والمدخلات غير الصالحة والتكرارات، وأعطِ كل سجل تسمية بسيطة تقول ما الذي يختبره. شغّل سير العمل على هذه المجموعة، وقارن النتائج بما دوّنته مسبقًا، وأبعد بيانات العملاء الحقيقية عن الجولات الأولى.
لماذا نختلق البيانات
الاختبار بسجلات حية يعني أن خطأً قد يراسل عميلًا حقيقيًا أو يغيّر طلبًا حقيقيًا. تصف وثائق n8n محاكاة البيانات (data mocking) بأنها إنشاء بيانات اختبار أو محاكاتها دون الاتصال بمصادر حقيقية، وتقول إن التثبيت (pinning) والمحاكاة يساعدان في حماية الأنظمة الحية من استدعاءات الاختبار المتكررة. كما أن اختلاق البيانات بنفسك يتيح لك تضمين حالات نادرة الحدوث لكنها مؤلمة إذا حدثت.
اختر الحالات عن قصد
لا تنسخ شريحة عشوائية من الشهر الماضي. قرر ما ينبغي أن يفعله سير العمل في كل حالة واختلق سجلًا لكل منها. مجموعة البداية المفيدة تبدو هكذا:
- سجل عادي ينبغي أن يمر مباشرة
- سجل عند كل حدّ، مثل أصغر كمية مسموحة وأكبرها
- سجل ينقصه حقل مطلوب
- سجل بتنسيق غير متوقع، مثل تاريخ مكتوب بطريقة أخرى أو اسم فيه علامة تشكيل
- تكرار لسجل سابق، يُرسل مرتين
- سجل ينبغي أن يذهب إلى شخص ليقرر بدلًا من معالجته تلقائيًا
- حقل نصي طويل جدًا أو فارغ
اكتب النتيجة المتوقعة أولًا
لكل سجل مُختلَق، اكتب ما ينبغي أن يحدث قبل أن تشغّل أي شيء: أي مسار يسلك، وأي رسالة تُرسل، وما الذي يُحفظ، وما الذي يُرفض. بدون هذه الملاحظة ستقرأ المخرجات وتقرر أنها تبدو صحيحة، وهذا اختبار أضعف من المقارنة بإجابة التزمت بها مسبقًا.
حاكِ المدخلات أو ثبّتها
يميّز n8n بين فكرتين. المحاكاة تنشئ بيانات اختبار، مثلًا بعقدتي Code أو Edit Fields. أما التثبيت فيحفظ البيانات، سواء كانت محاكاة أو حقيقية، ويعيد استخدامها في التنفيذات اللاحقة بدل جلب بيانات جديدة. كما يتيح تعديل البيانات المثبتة لاختبار سيناريوهات مختلفة دون إرسال كل منها من النظام الخارجي. وتقول الوثائق إن هاتين ميزتان للتطوير: فالتثبيت غير متاح في تنفيذات الإنتاج. أيًّا كانت الأداة، أبقِ مدخلات الاختبار منفصلة عن الإعداد الحي حتى لا تصل سجلات الاختبار إلى أنظمة حقيقية.
أبعد البيانات الشخصية
استخدم أسماء وعناوين مُختلَقة، وللبريد الإلكتروني استخدم أسماء أمثلة محجوزة مثل person@example.com وperson@example.invalid. تحتفظ IANA بالنطاقين example.com وexample.org لأغراض التوثيق وتقول إنه يمكن استخدامهما كأمثلة توضيحية دون تنسيق مسبق. ويحجز RFC 2606 أسماء النطاقات العليا .test و.example و.invalid و.localhost، ويصف .invalid بأنه مخصص لأسماء غير صالحة بوضوح من النظرة الأولى، وهذا يناسب عنوان اختبار لا ينبغي أن يخص شخصًا حقيقيًا أبدًا.
الاسم المحجوز تسمية وليس حاجزًا، فلا تعتمد على النطاق وحده لمنع رسالة من مغادرة نظامك. أوقف الإرسال الخارج في نسخة الاختبار من سير العمل، أو وجّهه إلى مَصرف مضبوط، أي صندوق بريد أو أداة التقاط تديرها أنت وتجمع الرسائل بدل تسليمها إلى مستلمين خارجيين. وتقول IANA أيضًا إن خدمات الويب لنطاقات الأمثلة لديها تُقدَّم على أساس بذل الجهد وغير مصممة لتطبيقات الإنتاج، فتجنّب التصاميم التي تحتاج إلى أن تستجيب هذه النطاقات.
إذا كان لا بد من الاختبار على نسخة من سجلات حقيقية، فعامل النسخة على أنها حساسة وقيّد من يستطيع رؤيتها. لا تترك رسائل الاختبار قادرة على الإرسال إلى عملاء حقيقيين أبدًا.
مثال افتراضي
تخيّل سير عمل يوجّه طلبات عروض الأسعار: الطلبات التي تقل عن قيمة معينة تحصل على إشعار استلام تلقائي، والأكبر تذهب إلى المالك. تضم مجموعة الاختبار طلبًا صغيرًا، وآخر عند الحد تمامًا، وآخر فوقه، وآخر بلا عنوان بريد، وآخر بعنوان بريد كُتب بمسافة في آخره، والطلب نفسه مرسلًا مرتين. تُكتب النتائج المتوقعة أولًا. يكشف الاختبار أن السجل عند الحد يُوجَّه في الاتجاه الخاطئ، وهذا أرخص اكتشافًا الآن منه بعد أن ينتظر عميل حقيقي. هذا المثال افتراضي.
احتفظ بالمجموعة وأعد استخدامها
احفظ سجلات الاختبار مع ملاحظات سير العمل. في كل مرة يتغير فيها سير العمل أعد تشغيل المجموعة وأضف سجلًا جديدًا كلما ظهرت مشكلة حقيقية. ومع الوقت تصبح المجموعة سجلًا لكل ما حدث فيه خطأ يومًا.