React Divense-Benover و DOM Testing Monorepo
مرحبًا بكم في تطوير Monorepo و DOM الذي يحركه مكونات React! يحتوي هذا المستودع على جميع التعليمات البرمجية والأمثلة لمحادثة شاملة حول بناء تطبيقات رد الفعل باستخدام التطوير الذي يحركه الاختبار (TDD) واختبار DOM. هنا رابط للحديث نفسه. تم تنظيم Monorepo باستخدام PNPM و Turborepo لتبسيط إدارة الحزم وبناء عمليات.
إذا لم تكن على دراية بمفهوم المونوروبو ، فهو مستودع واحد يحتوي على مشاريع متعددة. في هذه الحالة ، يحتوي Monorepo على مكتبة واجهة المستخدم المشتركة ، واثنين من تطبيقات React. تحتوي مكتبة واجهة المستخدم المشتركة على مكونات رد فعل قابلة لإعادة الاستخدام ويمكن الوصول إليها ، إلى جانب اختباراتها وقصصها. يوضح تطبيق React استخدام المكون والتكامل. يوضح تطبيق Next.js قوة التكوين في رد الفعل مع المكون المشروط لمكتبة Mantine UI.
يمكنك قراءة المزيد عن monorepos هنا.
ملخص
الهدف الأساسي لهذا المونوروبو هو إظهار أفضل الممارسات لبناء مكونات Reactable ويمكن الوصول إليها ، وكيفية اختبارها بشكل فعال باستخدام أدوات مثل React Testing Library and Storybook. بالإضافة إلى ذلك ، يعرض استخدام عامل خدمة وهمية للتعامل مع التبعيات الخارجية في الاختبارات ويوضح نمط الواجهة الخلفية (BFF) في العمل. تم تصميم الحديث لجمهور مع مزيج من الخبرة الأمامية والخلفية ، مع التركيز على قوة التكوين في React وكيفية تطبيقه على كل من تطوير المكون واختباره.
في النهاية ، نرى كيف يمكننا بناء واختبار هذه الواجهة:

محتويات
تم تنظيم monorepo على النحو التالي:
التطبيقات
-
frontend : تطبيق React الذي تم إنشاؤه باستخدام إنشاء تطبيق React لإظهار استخدام المكون والتكامل. -
mantine-example : تطبيق next.js يوضح قوة التكوين في رد الفعل مع مكون مكتبة Mantine UI. يتم استخدام هذا التطبيق كمقدمة للحديث ، مع تسليط الضوء على فوائد التكوين عند بناء واختبار مكونات رد الفعل.
حزم
-
ui : مثال على مكتبة واجهة المستخدم المشتركة التي تحتوي على مكونات رد فعل قابلة لإعادة الاستخدام ويمكن الوصول إليها ، إلى جانب اختباراتها وقصصها. -
types : مكتبة مشتركة تحتوي على أنواع TypeScript التي تستخدمها الحزم الأخرى. -
mocks : مكتبة مشتركة تحتوي على بيانات وهمية تستخدمها الحزم الأخرى.
ابدء
ستحتاج إلى تثبيت PNPM على مستوى العالم لتشغيل Monorepo.
إصدار PNPM المستخدمة عند تطوير هذا المونوربو هو 8.2.0 ، والإصدار العقدة 18.16.0 .
يحتوي إصدار Storybook المثبت على مشكلات عند تشغيل الإصدارات السابقة من العقدة. يرجى استخدام إصدار العقدة على الأقل 18.16.0 .
لتثبيت التبعيات من أجل monorepo ، قم بتشغيل الأمر التالي:
يمكن تشغيل monorepo باستخدام الأوامر التالية:
-
pnpm run dev : يدير المونوربو في وضع التطوير. -
pnpm run build : يبني monorepo للإنتاج. -
pnpm run start : تشغيل Monorepo في وضع الإنتاج. -
pnpm run test : يقوم بتشغيل اختبارات monorepo.
لتشغيل Storybook ، قم بتشغيل الأمر التالي:
إجراء اختبارات
يمكنك إما تشغيل جميع اختبارات الاختبارات لإعادة الريبو أو تشغيل اختبارات حزمة معينة.
لتشغيل جميع الاختبارات ، قم بتشغيل الأمر التالي:
لتشغيل اختبارات حزمة معينة ، قرص مضغوط في الدليل وتشغيل الأمر التالي:
لتشغيل اختبارات التطبيق ، قم بتشغيل الأمر التالي:
cd apps/frontend
pnpm run test -- --watch
لتشغيل اختبارات المكون ، قم بتشغيل الأمر التالي:
cd packages/ui
pnpm run test -- --watch
آمل أن تجد هذا monorepo مفيدًا في فهم أفضل الممارسات للتطوير القائم على المكون واختبار DOM. لا تتردد في استكشاف الكود ، وتشغيل الأمثلة ، والمساهمة في المستودع. ترميز سعيد!
ملاحظات إضافية
بنية API المقترحة للواجهة الأمامية الحديثة هي الواجهة الخلفية لنمط الواجهة الأمامية:

يمكنك قراءة المزيد عنها هنا.
من الذكاء الاصطناعى ملاحظات للحديث
إليك ملخص ووجبات رئيسية من العرض التقديمي:
ملخص: يعرض بول هاموند ، مدير برنامج Pack Software ، على التطوير الذي يحركه المكون مع اختبار React و DOM ، ويغطي مواضيع مثل التطوير الذي يحركه الاختبار ، وإمكانية الوصول ، والممارسات الأمامية الحديثة.
الأفكار:
- يساعد التطوير الذي يحركه المكون على بناء عناصر واجهة مستخدم قابلة لإعادة الاستخدام ومتسقة
- يوفر الاختبار ضد السلوك بدلاً من تفاصيل التنفيذ قيمة أكبر
- يجب أن تكون إمكانية الوصول بمثابة اعتبار رئيسي عند بناء مكونات الواجهة الأمامية
- تسمح أدوات مثل Storybook بالتطوير التفاعلي وتوثيق المكونات
- يمكّن عامل خدمة وهمية مكالمات API السخرية لكل من الاختبار والتطوير
- الواجهة الخلفية لنمط الواجهة الأمامية (BFF) يمكن أن تبسيط الهندسة المعمارية الأمامية
- تختبر الاختبارات الجيدة الثقة لإجراء تغييرات مع مرور الوقت
- تشجع مكتبة اختبار رد الفعل على الاختبار من منظور المستخدم
- يمكن أن يؤدي TDD إلى مزيد من الرمز القابل للصيانة والمرونة
- تسمح المكونات القابلة للتكوين بتخصيص وإعادة استخدام أسهل
رؤى:
- يتيح اختبار سلوك الاختبار بدلاً من التنفيذ إعادة صياغة وصيانة أسهل
- يمكن للمحددات التي يمكن الوصول إليها في الاختبارات تحسين إمكانية الوصول إلى التطبيق بشكل عام
- مستكشفو المكونات مثل Storybook يسهلون التعاون بين المصممين والمطورين
- يتيح الاستهزاء على مستوى الشبكة بتسخيلات متسقة عبر الاختبارات والتطوير
- يمكن أن يؤدي TDD إلى حلقات ردود فعل أسرع وثقة أعلى في تغييرات التعليمات البرمجية
- يمكن أن يساعد التركيز على نتائج التسليم في إقناع الفرق بتبني ممارسات TDD
- باستخدام DOM لاختبار عن كثب يقلد تفاعلات المستخدم الحقيقية
- إن فصل مخاوف واجهة المستخدم عن منطق العمل يحسن بنية التطبيق الإجمالية
- يمكن لممارسات التوصيل المستمر مثل "الهياكل العظمية للمشي" تحسين إعداد المشروع
- اختبارات وحدة الموازنة مع اختبارات التكامل/E2E تغطي سيناريوهات الاختبار المختلفة
يقتبس:
- "الغرض من الاختبارات الجيدة هو إعطائنا الثقة لإجراء التغييرات مع مرور الوقت."
- "إذا كانت الاختبارات تمر ، فيجب أن نشعر بالثقة الكافية للذهاب مباشرة إلى الإنتاج."
- "تم تصميم الأطراف الأمامية الحديثة بمكونات وليس صفحات."
- "يساعدنا التطوير المدفوع بالمكون على بناء مكونات قابلة لإعادة الاستخدام تقلل من الازدواجية."
- "نريد أن نرى كيف نجري التغييرات بمرور الوقت ، وكيف تساعدنا الاختبارات في إجراء تغييرات مع مرور الوقت."
- "يجب أن تعطينا الاختبارات الجيدة الثقة لإجراء تغييرات مع مرور الوقت."
- "فرحة TDD هي الطريقة الصحيحة لوضعها لأنها تجربة متحررة."
- "لم أعمل في وقت متأخر لمدة 10 سنوات ، ولأنني لست بحاجة إلى ذلك ، ولا يجب أن تحتاج إلى أن تكتب بأسلوب الاختبار الأول."
- "عندما يتعلق الأمر بالاختبار ، فإن أحد الأشياء التي عادة ما أقوم بها هي ... سأسحب فرع شخص ما إلى أسفل ، وأجري الاختبارات ، وفشل في شيء عن عمد ورؤية الاختبارات."
- "أنا بحاجة إلى الثقة هذه هي الطريقة التي تعمل بها."
العادات:
- اكتب الاختبارات قبل رمز التنفيذ لضمان تغطية الاختبار المناسبة
- استخدم المحددات التي يمكن الوصول إليها في الاختبارات لتحسين إمكانية الوصول الكلي
- التعاون عن كثب مع المصممين باستخدام أدوات مثل Storybook
- رمز Refactor بثقة مع مجموعة اختبار قوية في مكانها
- قم بإجراء اختبارات في وضع المراقبة للتغذية المرتدة أثناء التطوير
- استخدم عمال الخدمة الوهمية لمحاكاة استجابات API في الاختبارات
- بناء هياكل عظمية للمشي لإنشاء خطوط أنابيب CI/CD في وقت مبكر من المشاريع
- مراجعة طلبات السحب عن طريق كسر رمز عن قصد للتحقق من تغطية الاختبار
- إعطاء الأولوية لسلوك الاختبار على تفاصيل التنفيذ في الاختبارات الأمامية
- تعلم باستمرار وتطبيق أفضل الممارسات في التنمية الأمامية
حقائق:
- تم تصميم مكتبة اختبار React على رأس مكتبة اختبار DOM
- يستخدم Jest تمثيل DOM في الذاكرة يسمى JSDOM للاختبار
- يمكن لعامل خدمة وهمية اعتراض مكالمات API وسخرته على مستوى الشبكة
- Storybook هي أداة لتطوير مكونات واجهة المستخدم بمعزل عن
- تؤثر إمكانية الوصول على 30-40 ٪ من السكان بشكل ما
- التنمية التي تعتمد على المكون هي الإطار الغذائي وينطبق على رد الفعل ، vue ، الزاوي ، إلخ.
- يمكن أن يؤدي التطوير الذي يحركه الاختبار إلى عدد أقل من الأخطاء والمزيد من الكود القابل للصيانة
- يمكن أن تحسن الواجهة الخلفية لنمط الواجهة الأمامية الأداء الأمامي وتبسيط الهندسة المعمارية
- Cypress و Playwright هما أدوات للاختبار الشامل لتطبيقات الويب
- يمكن استخدام اختبار الطفرة للتحقق من جودة أجنحة الاختبار
مراجع:
- رد فعل مكتبة اختبار
- قصص
- عامل خدمة وهمية
- مزاح
- السرو
- الكاتب المسرحي
- Redux Toolkit
- رد فعل الاستعلام
- اختبار JavaScript (بقلم Kent C. Dodds)
- مبادرة الوصول إلى الويب W3C (WAI)
- حديث إيان كوبر "TDD: أين حدث كل شيء خطأ"
- Github Primer (مكتبة مكونات واجهة المستخدم)
- اختبار مكتبة ملعب
- الواجهة الخلفية لنمط الواجهة الأمامية (BFF)
واحد من الوجبات السريعة: يتيح التطوير الذي يحركه الاختبار مع مكتبة اختبار رد الفعل الكود الأمامي الواثق والقابل للصيانة من خلال التركيز على السلوك وسهولة الوصول إليه.
التوصيات:
- اعتماد التنمية التي تعتمد على المكون لتحسين قابلية إعادة الاستخدام والاتساق في التطبيقات الأمامية
- استخدم Storybook أو أدوات مماثلة لتطوير وتوثيق مكونات واجهة المستخدم
- تنفيذ ممارسات التطوير التي تعتمد على الاختبار للرمز الأمامي لتحسين الجودة
- ركز على اختبار السلوك بدلاً من تفاصيل التنفيذ للاختبارات الأكثر مرونة
- الاستفادة من عامل الخدمة الوهمية لاتصالات API المتسقة في الاختبارات والتطوير
- النظر في تنفيذ الواجهة الخلفية لنمط الواجهة الأمامية لتبسيط الهندسة المعمارية الأمامية
- إعطاء الأولوية لإمكانية الوصول في تصميم المكونات واختبارها من البداية
- استخدم محددات مكتبة اختبار React Testing لتحسين إمكانية الوصول إلى التطبيق بشكل عام
- تنفيذ ممارسات التكامل والتسليم المستمر في وقت مبكر من المشاريع
- اختبارات وحدة التوازن مع التكامل والاختبارات الشاملة للتغطية الشاملة