01 ديسمبر 2025·7 دقيقة
اختبار التطبيقات المولّدة بالدردشة: ماذا تختبر أولاً وما يمكنك تخطيه
خطة ذات أولوية لاختبار التطبيقات المولّدة بالمحادثة في React وGo APIs وFlutter: الحد الأدنى من فحوص الوحدة والتكامل وe2e التي تلتقط معظم الانحدارات.
خطة ذات أولوية لاختبار التطبيقات المولّدة بالمحادثة في React وGo APIs وFlutter: الحد الأدنى من فحوص الوحدة والتكامل وe2e التي تلتقط معظم الانحدارات.
تميل قواعد الكود المنتجة بالمحادثة إلى الفشل في نفس الأماكن لأن الشيفرة غالباً ما تُجمَع من قطع تبدو صحيحة لكنها لم تُجبر على التوافق مع بعضها. تعمل معظم الميزات في مسار السعادة، ثم تنهار عندما ينقر المستخدمون أسرع، يرسلون مدخلات غريبة، أو يستخدمون نسخة أقدم من العميل.
يقع الكثير من الخطر في كود الربط: الأجزاء الصغيرة التي توصل الشاشات باستدعاءات API، وتحوّل استجابات API إلى حالة واجهة المستخدم، وتحول مدخلات المستخدم إلى كتابات في قاعدة البيانات. هذه الأجزاء مملة، لذا تحصل على اهتمام أقل، لكنها تتحكم في تدفق التطبيق كله.
تتجمّع الانحدارات أيضاً حول الحدود حيث يجب أن يتشارك مكوّنان عقداً. تتوقع الواجهة شكلاً معيناً، فيرجع الـ API شكلاً آخر. يفترض الـ API أن قاعدة البيانات ستقبل قيمة، ثم يرفضها قيد. أو يغيّر أحد الطبقات التسمية أو الأنواع أو القيم الافتراضية ولا تتبعها الطبقات الأخرى.
تتكرر نفس نقاط الفشل مراراً وتكراراً:
يزيد السرعة من حدة المشكلة. تشجع منصات مثل Koder.ai على التكرار السريع: تطلب، تعيد توليد، تعيد صياغة، وتنتقل. هذه ميزة. لكنها تعني أيضاً أن التغييرات الصغيرة تحدث كثيراً، وتزداد فرصة كسر حد. عندما تشحن بسرعة، تحتاج اختبارات تعمل بسرعة وتفشل بصوت عالٍ.
الهدف هو الثقة، وليس الكمال. لست تحاول إثبات صحة كل سطر. تحاول التقاط التغييرات التي ستحرجك في الإنتاج: النموذج الذي لم يعد يحفظ، الـ API الذي بدأ يرفض طلبات صحيحة، أو تحديث قاعدة البيانات الذي يتوقف عن كتابة حقل بصمت.
توقع بسيط يساعد: احمِ العقود ومسارات المستخدم الأعلى أولاً. كل شيء آخر يمكن تأجيله حتى يثبت أنه يضر.
مع الشيفرة المولّدة بالمحادثة، لا يكمن الخطر الأكبر عادة في التجميع. بل في أن تغييرات صغيرة تكسر سلوكاً كنت تفترض أنه بديهي.
ابدأ بتسمية أعلى المخاطر بلغة بسيطة. إذا ضرب خطأ أيّاً من هذه، يصبح مكلفاً بسرعة:
بعد ذلك، اختر أصغر مجموعة اختبارات تغطي تدفقات المستخدم الحقيقية وعقود الـ API تحتها. قاعدة جيدة: مسار نجاح واحد بالإضافة إلى حالة “مدخل سيئ” لكل تدفق أساسي. على سبيل المثال، يجب أن يختبر “إنشاء عنصر” النجاح وفشل التحقق (حقل مطلوب مفقود)، لأن كلاهما غالباً ما يكسر عند تغير المطالبات.
ثم قرّر ما يجب التقاطه قبل الدمج مقابل قبل الإصدار. يجب أن يكون ما قبل الدمج سريعاً وموثوقاً. ما قبل الإصدار يمكن أن يكون أبطأ وأوسع.
مقياس أولوية بسيط يبقي النقاشات قصيرة:
مثال ملموس: ميزة “تغيير كلمة المرور” في تطبيق React مع Go API وعميل Flutter.
P0: يرفض الـ API كلمات المرور الضعيفة، يحدث الـ API الهاش المخزن، ويعرض كلا العميلين رسالة خطأ عند الفشل.
P1: تحديد الحد من المعدل وانتهاء الجلسة.
P2: حالات واجهة المستخدم بكسل-تامة.
إذا كنت تختبر تطبيقات مولّدة بالمحادثة (بما في ذلك مشاريع مبنية بأدوات مثل Koder.ai)، يساعدك عدسة 80/20 هذه على تجنّب عشرات الاختبارات الهشة التي لا تزال تفوّت الأخطاء التي يشعر بها المستخدمون فعلاً.
تأتي انحدارات React عادة من مكانين: أخطاء منطقية صغيرة (تشكيل البيانات، التحقق) وحالة واجهة لا تتطابق مع الواقع (التحميل، الأخطاء، الأزرار المعطلة). ابدأ حيث تؤذي الفشل المستخدمين.
إذا كانت الدالة لها مدخلات ومخرجات واضحة، اختبرها قبل أي واجهة. هذه الاختبارات سريعة ونادراً ما تكون متقلبة، وتحصنك من تغييرات سطر واحد تكسر الكثير.
أهداف جيدة أولاً: منسقات التاريخ والعملة، مدقّقات الحقول، تحويل استجابة API إلى نماذج عرض، والمخفّضات أو آلات الحالة التي تقود الشاشات.
بعد ذلك، اكتب بعض اختبارات المكوّنات للشاشات التي يستخدمها الناس لإنجاز العمل. بدلاً من العديد من لقطات السطح الضحلة، استخدم عدد قليل من الاختبارات التي تتصرف كمستخدم: اكتب في نموذج، اضغط زر، واثبت على ما يراه المستخدم.
ركّز على حالات واجهة المستخدم التي تنكسر عادة: تحقق النموذج وسلوك الإرسال، حالات التعطيل (بما في ذلك منع الإرسال المزدوج)، التحميل والمحاولة، عرض الأخطاء، وحالة الفراغ مقابل النتائج.
بالنسبة لأي شيء يتحدث إلى الشبكة، قم بمحاكاة عند الحد الفاصل. عامل عميل الـ API كفاصلة: اثبت شكل الطلب (الطريقة، المسار، معلمات الاستعلام الرئيسية، والpayload)، ثم أمد المكوّن باستجابة واقعية. هذا يلتقط انجراف العقود مبكراً، خاصة عندما يتم توليد أو تعديل الواجهة الخلفية بسرعة.
قاعدة واحدة تواصل جلب الفائدة: في كل مرة تصلح فيها خطأ، أضف اختباراً واحداً يفشل إذا عاد الخطأ. على سبيل المثال، إذا أرسلت صفحة مولّدة في Koder.ai مرةً userId بدل id، أضف اختباراً يتحقق من مفاتيح الحمولة الصادرة قبل المتابعة.
قد تبدو معالجات Go صحيحة بينما تخفي ثغرات منطقية صغيرة تتحول إلى أخطاء حقيقية. تكسبك أسرع الأمور من الاختبارات التي تقفل المدخلات، الأذونات، والقواعد التي تغير البيانات.
ابدأ بالتحقق من الطلبات. قد تقبل الشيفرة المولدة بالمحادثة سلاسل فارغة، تتجاهل أطوال الحد الأقصى، أو تطبّق القيم الافتراضية الخاطئة. اكتب اختبارات تستدعي المعالج (أو دالة التحقق التي يستخدمها) بحمولات سيئة وتؤكد على استجابة 400 واضحة مع خطأ مفيد.
بعد ذلك، ثبت المصادقة والأذونات عند الحافة. خطأ شائع هو “المصادقة موجودة، لكن الدور الخطأ لا يزال يستطيع التحديث.” اختبر مسار السعادة وبعض حالات الحظر ببناء طلب مع سياق مستخدم واستدعاء المعالج أو الـ middleware.
ثم ركّز على قواعد العمل التي تغير البيانات. تستحق نقاط النهاية create وupdate وdelete وأي نقاط idempotent (مثل “إنشاء إذا لم يكن موجوداً”) اختبارات صارمة. هذه هي الأماكن التي قد يتسبب فيها إعادة التصميم الصغيرة بالسماح بالتكرار، تخطي انتقال حالة مطلوب، أو الكتابة فوق حقول يجب أن تبقى ثابتة.
اجعل تعيين الأخطاء صريحاً. يجب على الـ API أن يترجم الفشل الشائع باستمرار إلى رموز الحالة الصحيحة: مدخلات سيئة (400)، غير موجود (404)، تعارض (409)، وأخطاء غير متوقعة (500). يجب أن تؤكد اختبارات الوحدة على كل من الرمز وشكل الخطأ الثابت حتى لا تنكسر العملاء.
الفحوص عالية العائد لتغطيتها مبكراً: الحقول المطلوبة والقيم الافتراضية، فحوص الأذونات لكل دور، عدم التأثر عند التكرار، وتطابق نظيف بين حالات الفشل الشائعة وأكواد الحالة.
تحافظ الاختبارات المدفوعة بالجدول على القراءات الحديّة مقروءة:
tests := []struct{
name string
body string
wantStatus int
}{
{"missing name", `{"name":""}`, 400},
{"too long", `{"name":"aaaaaaaaaaaaaaaa"}`, 400},
}
تأتي أخطاء Flutter في التطبيقات المولّدة بالمحادثة غالباً من افتراضات طرف العميل الصغيرة: حقل قد يكون null أحياناً، تاريخ يصل بتنسيق مختلف، أو شاشة تعلق في حالة التحميل بعد محاولة إعادة. يمكن لعدد قليل من الاختبارات المركزة أن تلتقط معظم هذه الأمور قبل أن تتحول إلى تذاكر دعم.
ابدأ بتحويل البيانات. الخطر الأكبر هو الحد الفاصل بين JSON ونماذج Dart الخاصة بك. اكتب اختبارات تغذي fromJson بحمولات تبدو حقيقية وتؤكد أنك تتعامل مع الحقول المفقودة، المفاتيح المعاد تسميتها، والقيم الغريبة. تعد enums والتواريخ من المشتبه بهم المعتادين: قيمة enum جديدة لا ينبغي أن تُسقط التطبيق، ويجب أن يفشل التحليل بأمان (مع خطأ واضح) بدلاً من إنتاج قيم خاطئة بصمت.
بعد ذلك، اختبر انتقالات الحالة. سواء كنت تستخدم BLoC أو Provider أو Riverpod أو setState بسيط، ثبّت ما يواجهه المستخدمون كل يوم: التحميل الأول، التحديث، الخطأ، وإعادة المحاولة. هذه الاختبارات رخيصة وتلتقط مشكلة “الدوران الأبدي” بسرعة.
مجموعة قصيرة تدفع في العادة ثمنها:
مثال ملموس: شاشة “إنشاء مشروع” مبنية بـ Koder.ai قد تقبل اسم المشروع والمنطقة. اختبر وحدة أن الاسم الفارغ ممنوع، وأن المسافات البيضاء تُقص، وأن قيمة منطقة لم تُرَ من قبل من الـ API لا تُسقط القوائم المنسدلة.
يمكن أن تساعد اختبارات Golden UI، لكن اجعلها نادرة. استخدمها فقط لشاشات مستقرة قليلة حيث تؤذي الانحدارات التخطيطية حقاً، مثل شاشة تسجيل الدخول، لوحة القيادة الرئيسية، أو تدفق إنشاء/دفع حرج.
عندما تبني بسرعة بأدوات المحادثة، تظهر أخطر الأخطاء بين الطبقات: صفحة React تستدعي API، معالج Go يكتب إلى Postgres، ثم تفترض الواجهة شكلاً استجابة تغيّر. اختبارات التكامل هي أسرع طريقة لالتقاط تلك الانقطاعات عبر الطبقات دون محاولة اختبار كل شيء.
قاعدة جيدة: لكل مورد أساسي (المستخدمون، المشاريع، الطلبات، إلخ)، اختبر مساراً واحداً حقيقياً مدعوماً بـ Postgres من طرف إلى طرف عبر Go API. ليس كل حالة. فقط مسار نجاح واحد يثبت أن الوصل يعمل.
ابدأ بمجموعة صغيرة من الفحوص ذات الإشارة العالية:
استخدم مثيل Postgres حقيقي لهذه الاختبارات (غالباً قاعدة بيانات قابلة للإتلاف). قم بتهيئة فقط ما تحتاجه، ونظّف بعد كل اختبار، وركّز التأكيدات على الأشياء التي يلاحظها المستخدمون: البيانات المحفوظة صحيحة، تُطبق الأذونات، والعملاء يستطيعون تحليل الاستجابات.
مثال: ميزة “إنشاء مشروع”. اختبار التكامل في Go يستدعي POST /projects، يتحقق من استجابة 201، ثم يجلب المشروع ويؤكد الاسم ومعرّف المالك. اختبار التكامل في React يقدّم نموذج الإنشاء ويؤكد أن حالة النجاح تظهر الاسم الجديد. اختبار Flutter يفتح قائمة المشاريع، ينشئ مشروعاً، ويتأكد من ظهوره بعد التحديث.
إذا ولّدت تطبيقات على Koder.ai، تحمي هذه الاختبارات أيضاً عندما تغير الواجهة أو المعالجات شكلاً الحمولة أو صيغة الخطأ عن غير قصد.
اختبارات E2E هي شبكة الأمان “هل يعمل التطبيق من الطرف إلى الطرف؟”. تكون ذات قيمة أكبر عندما تبقى صغيرة ومملة: اختبارات دخان تثبت أن الاتصال بين React وGo API وPostgres والعميل Flutter لا يزال قائماً بعد التغييرات.
اختر فقط حفنة من الرحلات التي تمثل المال الحقيقي أو الألم الحقيقي عند تعطلها: تسجيل الدخول/الخروج، إنشاء سجل، تحرير وحفظ، البحث/التصفية وفتح نتيجة، والدفع/العملية إن وجدت.
شغّل هذه على متصفح واحد وملف تعريف جهاز واحد أولاً (مثلاً، Chrome للويب وحجم هاتف نموذجي للمحمول). وسّع إلى متصفحات أو أجهزة أخرى فقط عندما يبلغ العملاء عن مشكلات فعلية هناك.
الاستقرار ميزة. اجعل الاختبارات حتمية بحيث تفشل فقط عندما يتعطل شيء فعلاً:
استخدم E2E للتحقق من المسار الرئيسي، وليس كل حالة حديّة. تنتمي الحالات الحديّة لاختبارات الوحدة والتكامل حيث تكون أرخص وأقل هشاشة.
أسرع طريقة لإضاعة الوقت هي كتابة اختبارات تبدو شاملة لكنها نادراً ما تلتقط أخطاء حقيقية. مجموعة صغيرة مركزة أفضل من شبكة واسعة لا يثق بها أحد.
اختبارات اللقطات شائعة الكمين في React وFlutter. لقطات كبيرة تتغير لأسباب غير مؤذية (تعديلات نص، تحولات في التخطيط، إعادة تصميم بسيطة)، لذلك إما يقبل الفريق تحديثات مزعجة أو يتوقف عن متابعة الفشل. احفظ اللقطات لسطح مستقر صغير، مثل نتيجة منسق صغيرة، لا لشاشات كاملة.
تجاوز اختبار مكتبات الطرف الثالث. لا تحتاج لإثبات أن React Router، أو منتقي تاريخ، أو عميل HTTP يعمل. اختبر نقطة التكامل الخاصة بك بدلاً من ذلك: المكان الذي تُكوّن فيه أو تُحوّل البيانات أو تتعامل مع أخطائه.
نادراً ما تستحق اختبارات التنسيق (styling) العناء. فضّل فحوص السلوك (الزر معطل عندما يكون النموذج غير صالح، عرض رسالة خطأ عند 401) على تأكيدات على مستوى البكسل. اجعل استثناء عندما يؤثر التنسيق على السلوك أو الامتثال: متطلبات التباين، مخططات التركيز لمستخدمي لوحة المفاتيح، أو تخطيط استجابي حرج يغير ما يمكن للمستخدمين فعله.
تجنّب تكرار نفس الفحص في كل طبقة. إذا أكدت بالفعل في اختبار تكامل Go أن الطلبات غير المصرح بها ترجع 401، ربما لا تحتاج لنفس التأكيد في اختبارات الوحدة وE2E معاً.
اختبارات الأداء تستحق العناء، لكنها لاحقاً. انتظر حتى يستقر مسار التطبيق (مثلاً بعد أن يتوقف ميزة مولّدة بـ Koder.ai عن التغير اليومي)، ثم حدد هدفاً أو اثنين قابلين للقياس وتتبعهما باستمرار.
افترض أنك تُطلق ميزة بسيطة: مستخدم مسجل يدخل إلى حسابه ويعدّل ملفه ويغيّر بريده الإلكتروني. هذه كانتير جيدة لأنها تمس حالة واجهة المستخدم، قواعد API، وتخزين العميل.
إليك مجموعة الاختبارات الدنيا التي عادةً تلتقط معظم الانحدارات دون أن تتحول إلى مجموعة كاملة للاختبارات.
updated_at يتغير) عندما يتغير البريد.تستهدف هذه المجموعة نقاط الانهيار الشائعة: تحقق واجهة المستخدم وحالات التعطيل في React، انجراف القواعد في Go، وواجهات المستخدم المتقادمة أو المربكة في Flutter. إذا بنيت باستخدام منصة مثل Koder.ai، حيث قد يتغير الكود عبر الطبقات بسرعة، تعطيك هذه الاختبارات إشارة سريعة مع صيانة دنيا.
اضبط المؤقت على 60 دقيقة وركّز على المخاطر، لا الكمال. قد تبدو الشيفرة المولّدة بالمحادثة صحيحة لكنها قد تفوّت قواعد صغيرة أو حالات حديّة أو وصلات بين الطبقات. هدفك مجموعة اختبارات قصيرة تفشل بصوت عالٍ عندما يتغير السلوك.
اكتب 5 إجراءات للمستخدم يجب أن تعمل دائماً. اجعلها ملموسة: "تسجيل الدخول"، "إنشاء طلب"، "الدفع"، "رؤية تاريخ الطلب"، "إعادة تعيين كلمة المرور". إذا كنت تبني في Koder.ai، اختر ما يمكنك عرضه من طرف إلى طرف اليوم.
لكل تدفق، اعثر على قاعدة واحدة قد تسبب ضرراً حقيقياً إذا كانت خاطئة. أضف اختبار وحدة سريع واحد لكل طبقة حيث توجد هذه القاعدة:
مثال: "يجب ألا يسمح السلة بكمية سالبة." اختبرها مرة واحدة في الـ API، ومرة في واجهة المستخدم إذا طبقتها هناك أيضاً.
أضف اختبار تكامل واحد لكل تدفق يضرب الـ API الحقيقي ويجري كتابة قاعدة بيانات حقيقية في Postgres. اجعله ضيقاً: إنشاء، تحديث، جلب، والتحقق من النتيجة المخزنة. هذا يلتقط أخطاء التوصيل مثل أسماء الحقول الخاطئة، المعاملات المفقودة، أو الهجرات المكسورة.
اختر 3 إلى 6 تدفقات E2E إجمالاً. فضّل المسارات عبر الطبقات الأكثر تداخلاً (تسجيل الدخول → إنشاء → عرض). حدّد بيانات اختبار ثابتة (مستخدم مهيأ، معرفات معروفة، ساعة ثابتة) حتى لا تعتمد الاختبارات على العشوائية.
شغّل الاختبارات بهذا الترتيب في CI: اختبارات الوحدة على كل دفع، اختبارات التكامل على كل دفع أو على الفرع الرئيسي، وE2E فقط على الفرع الرئيسي أو ليلاً حيثما أمكن.
أسرع طريقة لإضاعة الوقت هي اختبار الشيء الخطأ بالمستوى الخاطئ من التفاصيل. معظم الفشل قابل للتوقع: عقود غير واضحة، محاكيات غير واقعية، ومجموعة لا يثق بها أحد.
خطأ شائع هو البدء بالاختبارات قبل الاتفاق على عقد الـ API. إذا تغيّر Go API رموز الأخطاء، أسماء الحقول، أو قواعد الصفحات، فسيفشل React وFlutter بطرق تبدو عشوائية. اكتب العقد أولاً (الطلب، الاستجابة، رموز الحالة، أشكال الأخطاء)، ثم اقفله ببعض اختبارات التكامل.
كمين آخر هو الإفراط في استخدام المحاكيات. المحاكيات التي لا تتصرف مثل Postgres أو middleware المصادقة أو استجابات الشبكة الحقيقية تُعطي شعوراً زائفاً بالأمان. استخدم اختبارات الوحدة للمنطق الخالص، لكن فضّل اختبارات التكامل الرفيعة لأي شيء يعبر حدود العملية.
الفخ الثالث هو الاعتماد على E2E لكل شيء. E2E بطيئة وهشة، لذا يجب أن تحمي فقط رحلات المستخدم الأعلى قيمة. ضع معظم التغطية في اختبارات الوحدة والتكامل حيث تكون الأخطاء أسهل في التشخيص.
أخيراً، لا تتجاهل التقلب. إذا فشلت الاختبارات أحياناً، يتوقف الفريق عن الاستماع. عامل الاختبارات المتقلبة كأخطاء في خط التسليم وأصلحها بسرعة.
قائمة تحقق سريعة قبل إضافة مزيد من الاختبارات:
الخطوات التالية: نفّذ الخطة، تابع الانحدارات حسب الطبقة، وابقِ الجناح صغيراً عن قصد. إذا بنيت مع Koder.ai، من المفيد إضافة اختبارات مباشرة بعد تأكيد عقد الـ API المولد وقبل توسيع الميزات.
إذا كنت تعمل على تطبيقات مولّدة عبر Koder.ai وتريد مكاناً واحداً للتكرار عبر الويب والخلفية والمحمول، تم تصميم المنصة على koder.ai حول سير العمل هذا. أيّاً كان الأداة التي تستخدمها، تظل مقاربة الاختبار نفسها: ثبّت العقود، غطِّ الطرق الرئيسية، واجعل الجناح مملاً بما يكفي لتشغله فعلاً.
تتعطل غالباً عند الحدود: واجهة المستخدم ↔ API ↔ قاعدة البيانات. قد تبدو القطع المولدة صحيحة كلٌ على حدة، لكن عدم تطابق العقود الصغيرة (أسماء الحقول، الأنواع، القيم الافتراضية، رموز الحالة) يظهر عندما يتصرّف المستخدمون بشكل “فوضوي” مثل النقر المزدوج، إرسال مدخلات غريبة، أو استخدام عميل أقدم قليلاً.
اختبر أولاً ما يربط الأجزاء: تدفقات المستخدم الرئيسية وعقود API التي تحتها. مجموعة صغيرة تغطي “إنشاء/تحديث + تحقق + حفظ + قراءة” عادةً تكتشف أخطاء حقيقية أكثر من كثير من لقطات واجهة المستخدم.
ابدأ بالمخاطر التي تصبح مكلفة بسرعة:
ثم اكتب أصغر الاختبارات التي تثبت أن هذه الأمور لا يمكن أن تنحرف بصمت.
استخدم سلماً بسيطاً:
قرّر الفئة أولاً، ثم اكتب الاختبار.
ابدأ باختبارات المنطق البحت (المنسّقات، المدقّقات، تحويل استجابات API إلى نماذج العرض، المخفّضات/آلات الحالة). ثم أضف بعض اختبارات المكوّنات التي تتصرّف كمستخدم:
حاكِ مخرِج الشبكة عند الحد الفاصل للعميل، واثبت على شكل الحمولة الصادرة حتى يتم رصد انحراف العقود مبكراً.
ثبت أربعة أشياء:
اجعل الاختبارات مدفوعة بالجدول حتى تظل إضافة الحالات الحديّة سهلة.
ركّز على حدود JSON → النماذج وحركات الحالة:
fromJson يجب أن يتعامل مع الحقول المفقودة/القابلة لأن تكون null دون تعطلوأضف اختباراً واحداً يتأكد من عرض رسالة ودّية عندما يرجع الخادم أخطاء تحقق.
تلتقط أخطاء الربط بين الطبقات:
اجعل كل اختبار لحالة واحدة مع بيانات تمهيدية ضئيلة حتى يبقى مستقراً.
خليه مملّاً وقليل العدد:
اجعلها حتمية بتسجيلات حساب اختبار ثابتة، بيانات تمهيدية، انتظارات واضحة (لا تستخدم sleeps عشوائية)، وإعادة ضبط بين التشغيلات.
تأجيل الاختبارات التي تصدر ضوضاء أو تكرر نفس الضمان:
أضف الاختبار عندما تصلح خطأ حقيقي؛ بهذه الطريقة ينمو الجناح من الألم الفعلي.