مرحباً بالجميع ، اسمي ياروسلاف أستافييف ، واليوم أود إجراء جولة بصحبة مرشدين في اختبار ReactJS. لن أتطرق إلى تعقيد اختبار تطبيقات الويب باستخدام مكتبات معينة (وفقًا لمقاربة "من الصعب اختبار الكود السيئ فقط") ، وفي المقابل سأحاول تنويع آفاقك. إذن في هذه المقالة ، React هي أكثر من مناسبة لتجميع طرق الاختبار ، وهي نقطة بداية تجمع بين محبو موسيقى الجاز والتكنولوجيا. سيكون من الأصح القول أننا سنتحدث عن مبادئ الاختبار بشكل عام مع الرسوم التوضيحية على ReactJS (وليس فقط).
إذا كنت تعتبر نفسك مرشد اختبار -
تخطي النصف الأول من المقالة ، فهو يتعلق بالمبادئ الأساسية للاختبار. إذا كان الجزء الثاني لا يكشف عن أي شيء جديد بالنسبة لك ، تعال إلينا للعمل وتعليم كيفية.
إذا لم تتسبب المقدمة في حدوث نوبة من التخليق ، مرحبًا بك في cat.
اختبارات الوحدة
Unit Jest هي مكتبة لاختبار JavaScript. لا أحب هذا - خذ
آخر ، ولكن بعد ذلك
آفا أفضل. كل شيء بسيط هنا: انقر فوق الزر السحري وتأكد من أن قيمة معينة من "0" قد تغيرت إلى "1":
import React from "react" import { MyButton } from "../src/components/dummy/myButton" import renderer from "react-test-renderer" test("MyButton has onPress fn", () => { let x = 0 const instance = renderer .create(<MyButton onPress={() => x++} />) .getInstance() expect(instance.handlePress).toBeDefined() expect(x).toBe(0) instance.props.handlePress() expect(x).toBe(1) })
الآن لديك كل المهارات اللازمة لاختبار الزر السحري. لسوء الحظ ، لا ترتبط هذه المهارات بالحياة الحقيقية. لا يمكن عزل مكون التفاعل بشكل جيد ، والعزلة هي واحدة من المبادئ الرئيسية لاختبار الوحدة. بطريقة ما ، من الضروري إزالة جميع المكونات التي تشارك بطريقة ما في طريقة التجسيد ، باستثناء المكون الذي تم اختباره. وهناك حل: لقد توصل الأشخاص الأذكياء إلى mockAPI لهذا الغرض.
جوهر Mock بسيط: كل ما ليس لنا هو
Mock / Stub / Fake / Dummy / Spy الخ. نحن "نحاكي" الطريقة التي نحتاج بها إلى السلوك الحقيقي لأحد المكونات ، والذي يمكن أن يكون له منطق معقد ، على بيانات اختبار مُعدة مسبقًا ونفهم أن جميع المكونات التي تمت مضاهاتها تعمل بشكل مثالي إذا كانت المعلمات الصحيحة مدخلات لها.
هناك مكتبة
jest-fetch-mock لـ
jest ، حيث يمكنك تعريف moki على المستوى العالمي. إذا كنت لا تحب هذا الخيار ، فيمكنك "تبليل" كل مكون تحتاجه في الاختبار بشكل منفصل.
دالة خالصة على نفس الإدخال ترجع دائمًا نفس الإجابة. وفقًا لذلك ، إذا كانت المكونات في منطق أعمالنا تحتوي على وظائف / مكونات "غير نظيفة" ، فعندئذٍ في اختبارات الوحدة ستحتاج أيضًا إلى "مسح" (ولكن بالنسبة لاختبارات الوحدات ، فإن هذه القاعدة ليست صحيحة دائمًا). المثال الكلاسيكي هو مكون التفاعل الذي يعرض التاريخ والوقت الحالي بالتنسيق الذي تحتاجه ، وسيكون التاريخ مختلفًا في كل مرة تقوم فيها بإجراء الاختبارات ، ولن تكون قادرًا على كتابة اختبارات الوحدة الصحيحة. بالنسبة إلى كل من لا يوافقون ، يمكنك تعقيد المثال حيث يجب أن يعرض المكون الخاص بك التاريخ بالتنسيق النسبي وأن يبرز التواريخ التي مضى عليها أكثر من
عام من التاريخ
الحالي باللون الأحمر.
وفقًا لذلك ، إذا كان لديك أشياء ديناميكية تعتمد على الوقت / الطقس / الضغط ، فسيقوم الوهمية بإعادة تعريف المكالمة التي تحتاجها حتى لا يكون هناك اعتماد على عوامل خارجية. وبالتالي ، لا يتعين عليك الانتظار
يوم 29 فبراير للوقوف على اختبار سقط.
قواعد اختبار الوحدة
المشكلات الموضحة أعلاه وطرق حلها هي محاولات لإيجاد طريقة غير رسمية للاختبار: كل اختبار يعمل كما يريد. في رأيي ، يكفي الالتزام
بثلاث قواعد مهمة لاختبار الوحدة :
- الحتمية
- العزلة
- الاستقلال عن العوامل الخارجية
- الفطرة السليمة
القاعدة الأولى: يجب أن تكون جميع الاختبارات حتمية. إذا كتبت اختبارًا على نظام التشغيل Windows ، فعندئذٍ على نظام التشغيل Mac ، فيجب أن يبدأ وينتج نفس النتيجة. يحب مطورو Windows نسيان أن أسماء الملفات على أنظمة * nix حساسة لحالة الأحرف. وأنت محظوظ إذا كانت
الاختبارات تندرج في إطار CI ، وليس التطبيق في الإنتاج .
القاعدة التالية هي العزلة. نحن نبلل جميع المكونات غير المختبرة. إذا كان هذا أمرًا صعبًا ، فقد حان الوقت لإعادة التفاعل.
أخيرًا وليس آخرًا: إذا كانت هناك بيانات يتلقاها التطبيق الخاص بك في وقت التشغيل ، فيجب أيضًا أن يتم تسميرها. يمكن أن يكون هذا لغة ، حجم النافذة ، تنسيق التاريخ ، تنسيق رقم الفاصلة العائمة ، إلخ.
اختبارات التكامل
عندما أبدأ كتابة اختبارات التكامل ، في رأيي ، سؤال مفتوح ، وفي كل فريق / منتج فردي ، يجب اتخاذ القرار مع مراعاة العوامل الداخلية.
يمكنك اتباع نهج رسمي: تحقيق تغطية
اختبار وحدة بنسبة 80 ٪ (يجب عدم مراجعة الاختبارات المكتوبة بشكل سيء / تتطلب فقط رمز جديد أو تغيير ليتم تغطيتها بواسطة الاختبارات) ، ثم إجراء مراجعة كاملة وإعادة تجهيز جميع الاختبارات المكتوبة مع تحليل الأخطاء النموذجية ، وإضفاء الطابع الرسمي على القواعد الداخلية لكتابة الاختبارات و تنفيذ مثل هذه الغارات سنويا. بعد كل الإجراءات الموضحة أعلاه ، لا تزال تغطية كود الاختبار 80٪ + ، عندئذ يكون لديك فريق ناضج ، أو أنك ببساطة لا تنتقد الشفرة / الاختبارات. إذا أصبحت تغطية الشفرة أقل ، فأنت بحاجة إلى تحقيق تغطية بنسبة 80٪ مرة أخرى والمضي قدمًا في كتابة اختبارات التكامل. يمكنك الخروج بشكل أقل رسمية وببساطة تسترشد بالفطرة السليمة: على سبيل المثال ، لكل خطأ تم لعبه في أوقات n ، اكتب اختبارًا أو توصل إلى شيء آخر ، على سبيل المثال ، إرم عملة معدنية.
السؤال المفتوح الثاني:
ما هي الاختبارات التي تعتبر التكامل ؟ ربما اتركه بلا إجابة.
في اختبارات التكامل ، نقوم باختبار عمل مكون واحد ، ولكن عدة مكونات في مجموعة. لا توجد قواعد ، لكن المنطق السليم يخبرك:
- لا تختبر كيف يتم تقديمها ، وأين تُسمى ، ومتى سينتهي كل شيء ؛
- لا تختبر عمل ReactJS ، إذا لم تنجح ، فلن يساعدك شيء ؛
- لا تختبر كيف تعمل آلة الحالة React ؛
- اختبار منطق العمل / نموذج البيانات / حالات الشريط الحدودي / شيء غالبًا ما ينهار.
في مثل هذه الاختبارات ، يجب ألا تدخل في التفاصيل. يتم تشغيلها لفترة أطول بشكل ملحوظ ، كما أنه من الصعب كتابتها ، لذا لا ينبغي عليك القيام بها وتغطية كل حالة بسيطة في منطق التطبيق. هذا مكلف من حيث تأجير البنية التحتية ، وطويل من حيث التطوير ووقت تنفيذ البرنامج النصي. سيقضي شخص ما حياته على هذا الروتين ،
وسيكون مدير المستخدم حزينًا ، وينتظر ميزات جديدة ، و ...
سبب آخر لعدم محاولة اختبار كل شيء هو False Security (لقد حاولت كتابة أهم النقاط أعلاه). يجب على كل فريق أن يقرأ عن الأخطاء من النوع الأول والثاني ، وهي نيومان بيرسون ، وتقييم مخاطرها من حيث المال أو الببغاوات أو غيرها من مقاييس الحقيقة المقبولة في الفريق.
ولكن هناك استثناءات لهذه القاعدة ، وكذلك لأي دولة أخرى.
ننسى كل ما يقال أعلاه :
- عند اختبار التبعيات الديناميكية. عندما لا تعرف أي مكون سيأتي في وقت التشغيل ، يمكنك تقديمه ، لكن قد لا يأتي. أنت أيضا بحاجة إلى كتابة اختبار لهذا ، لا أحد ألغى دارة الدائرة. إما المكون الخطأ الذي توقعته ، أو سوف يأتي مكون مكسور. لذلك ، في هذه الحالة ، نكتب اختبار التكامل وتقديم. نتحقق مما إذا كان كل شيء يعمل ، إذا لم يسقط شيء.
- باستخدام بيكسل مثالي (جيدًا ، تفهم) ، سيتعين على التطوير تقديم لقطات شاشة مختلفة ، وفي كل مرة يتم تحديث مكتبة المكونات إلى إصدار جديد - قم بتحديث لقطات الشاشة المرجعية. لأنه من الأسهل
استئجار مصمم جديد للتصالح بدلاً من الإصلاح.
اختبارات لقطة
أبسط اختبار التكامل هو لقطة:
- نأخذ عنصرا ، وجعله
- في العرض ، نكتب console.log (هذا)
- نسخ البيانات المرجعية من وحدة التحكم
- قارن
إذا كنت ترغب في
الشعور بالارتباك قليلاً ، فإنني أنصحك بالتجول مع مكتبة
StoryBook . هذه مكتبة لاختبارات اللقطة ، التي اختتمت بالمناسبة فكرة
StyleGuidist - إنشاء نظام التصميم الخاص بك على أساس مكونات React.
القاعدة الأولى لاختبار اللقطة:
لا تخبر أبدًا ، فحاول اختبار البيانات . يجب أن تكون دائمًا ثابتة ، "مغلقة" ومستقلة. القاعدة الثانية:
اختبار لقطة معطلة لا يعني أن كل شيء سيء . إذا كان أحمر - وليس حقيقة أن كل شيء ذهب. هناك العديد من الخيارات لجعل التخطيط نفسه ، لكن شجرة DOM كانت مختلفة. لذلك نتجاهل المسافة البيضاء أو السمات أو المفاتيح أو لا نختبر ما يتطلب الكثير من وقت الدعم. أو نحتفل بأيدينا بما هو مكسور ، ما هو غير مكسور. نقوم بإصلاح الاختبارات المعطلة وإعادة تشغيل StoryBook في وضع التحديث الوهمي - وهو الوضع الذي سيعرض فيه الاختبار المكونات وإدراج Snapshot كقيمة مرجعية في حالة توقع.
xState والرد التلقائي
ReactJS هو شيء صعب. يبدو أن المكتبة رائعة. لقد صنعت ثلاثة مكونات - فئة: ويبدو أن آلة الحالة تعمل والرمز جميل. ثم تكتب على ReactJS لمدة ستة أشهر ، تنظر إلى الكود - نوع من الهراء. أنت لا تفهم أين العكازات ، أين الطرق ، الدولة ، المكان الذي توجد فيه ذاكرة التخزين المؤقت ... ثم تفكر: حسنًا ، سأفعل ما تنصح به فيسبوك: سوف أقوم بتثبيت "hokeys" ، "hooks" ، شيء آخر ، وفجأة أفكر كيف تفكر في حبك. رو في محاولات لإيجاد مشروع مع تطور على رد الفعل من الصفر ، لذلك بالتأكيد هناك بالتأكيد
كل ما في وسع ...
كل شيء معقد لدرجة أنه من المستحيل عمومًا فهم كيفية عمله. وهو يعمل حتى يشكو شخص ما. نحن نصلحها - ويصلحها ، لكننا نلتف حولها ... أحد المخرجات هو
آلة الحالة ، ومجموعة من حالات التطبيق الحتمية والانتقالات المسموح بها بينهما. وكما يقولون في دوائر ضيقة ، لم تكتب على رد الفعل إذا لم تقم بضرب آلة الحالة الخاصة بك.
يجدر التذكير
xState . هذا هو جهاز الدولة الحتمية لجافا سكريبت.
يمكنك إنشاء واجهة مستخدم رائعة جدًا على
xState - يمكن العثور على رابط للتقرير المطابق في وثائق مكتبة
React Automata . بدورها ، React Automata هي المكتبة التي تم فيها تكييف xState في ReactJS. بالإضافة إلى ذلك ، فهي قادرة على
إنشاء اختبارات لحالة جهاز الحالة .
إذا كان لدينا علامة التجزئة الأولى صحيح - الضوء الأخضر في وضع التشغيل. إذا كان الثاني خاطئًا ، فسيتم رسم كلب رمادي ، ويقوم React Automata بإجراء اختبارات لجميع المجموعات الأربعة من هذه المعلمات والتحقق من صحة الكلب والمصباح. ومع ذلك ، في مرحلة ما سوف ترغب في خفض نصف الاختبارات ، ولكن في البداية ستكون سعيدًا للغاية ... على أي حال ، هذه نظرة مريحة على اختباراتك من الجانب ، إنها تذكرني كثيرًا بفكرة الاختبار بفوضى حتمية.
السرو
باستخدام اللقطة ، اكتشفنا أكثر أو أقل ، يمكنك التوجه نحو النهاية 2. لدينا جميع المنتجات الداخلية ، لذا فإن الحلول المحلية هي الخيار الوحيد لدينا. آمل أن تتاح لك الفرصة لاستخدام الحلول السحابية ، عندئذٍ سيكون مثل
Cypress مفيدًا.
في السابق ، اخترت اختبار الأُطر ، وأخذت المكتبات للتأكيد ، والمكتبات لمقارنة XML معقدة. ثم اخترنا سائق ومتصفح لبدء كل شيء. بدأوا وكتبوا مجموعة من الاختبارات. كل هذا يستهلك البنية التحتية ، تحتاج إلى إدخال كل شيء في عامل الإرساء ، ثم تثبيت بعض الأشياء التي تنظر إلى الاختبارات في الديناميات ، ويحللها ، ويظهر ما هو الخطأ ...
الرجال السرو فعلوا كل شيء من أجلك. لقد حلوا العديد من المشكلات:
إعداد بيئة العمل ، كتابة التعليمات البرمجية ، اختبارات التشغيل والكتابة. إذا تم كسر الاختبار ، فيمكنك عرض لقطة شاشة توضح ما تم كسره. صحيح ، إنه لا يعمل للهواتف المحمولة ، ولكن هناك ، على سبيل المثال ، هو
التخلص من السموم . هذا ، بالطبع ، صعب من وجهة نظر عتبة الإدخال: سيتعين عليك تصميم التطبيق الخاص بك عليه ، وإعادة كتابة مجموعة من الملفات ، إلخ. ولكن إذا كنت تريد ذلك ، فهذا ممكن.
اختبارات لينة
هناك أنواع بديلة من الاختبارات التي لا يمكن أن تسمى اختبارات جيدة أيضًا. أنا أسميها اختبارات لينة. على سبيل المثال ، linter. يتم استخدامها بشكل رئيسي من قبل الواجهة الأمامية (وحتى في بعض الأحيان ، يأتي الإلهام إلى javists). هناك العديد من
اللاعبات :
ESLint ،
JSHint ،
Prettier ،
Standard ،
Clinton . أنصح
أجمل: بسرعة ، ورخيصة ، البهجة ، وسهلة التكوين ، ويعمل خارج الصندوق .
إذا كنت ترغب في الحصول على الخلط ، يمكنك تكوين ESLint. واسمحوا لي أن أقدم لك مثالًا كلاسيكيًا للمكون الإضافي له: عندما يعثر العميل على تعليقات بتعبيرات فاحشة في شفرتك ، فإنه يقسم عادةً. يقوم المطورون الصعبة بإبداء تعليقات باللغة الروسية حتى لا يخمن العميل ذلك. لكن العميل خمن ... استخدم مترجم Google واكتشف كل شيء يفكر فيه المطورون. المخرج من الوضع غير سار ، ربما مع فقدان المال أو العملاء. بالنسبة لهذه الحالات ،
يمكنك دائمًا تطوير مكون إضافي لـ ESLint ، والذي يجد الكلمات "الروسية الأصلية" في التعليمات البرمجية المصدر ويقول: "أوه ، آسف ، رفض التزامك."
إن جمال اللنترات في جافا سكريبت هو أنه
يمكن وضعها على خطاف مسبق الالتزام . أنا شخصياً لا أحب أن Prettier لا يخزن التاريخ (على الرغم من أنه ، من ناحية أخرى ، لا يتراكم الدين الفني أيضًا). من وجهة نظر التحليل الإحصائي للرمز ، فإن هذه الاختبارات بائسة ، لأنه لا يمكنك رؤية ديناميكيات المشروع ، ومعرفة عدد الأخطاء التي وقعت بالأمس ، أول من أمس. من حيث المبدأ ، تم حل هذه المشكلة في
SonarQube ، كما أنها في حل السحابة. هذا محلل كود إحصائي يخزن تاريخ التشغيل ، ويمكنه العمل مع أكثر من عشرين لغة ، بما في ذلك PHP (من آخر لا يحتاج إلى اليد الحديدية للتحليل الثابت؟ :)). في ذلك ، يمكنك مشاهدة ديناميكية نقاط الضعف الخاصة بك ، والأخطاء ، والديون الفنية وأكثر من ذلك.
اختبارات التعقيد
يستخدم
Frontenders اللمبات لأنهم يريدون المسافة البادئة الجميلة . التعقيد هو أيضًا اختبار بسيط يمكنك من خلاله التحقق من جودة الكود.
تُظهر الصورة كيف أحاول متابعة فكر المبتدئ الذي قدم طلب السحب. في مثل هذه الحالات ، أقترح هدم كل شيء وبناء طريق مباشر.تتبع اختبارات التعقيد مبدأً بسيطًا للغاية: فهي تحسب
التعقيد الدوري للخوارزمية. على سبيل المثال ، قاموا بقراءة دالة ، والعثور على 10 متغيرات فيها. إذا 10 - ربما كان من الصعب. هيا نضع التعقيد 1. في كل دورة ، سنعطي 3 نقاط ، لكل دورة في دورة - 9 ، لكل دورة في دورة ما من دورة - 27. نضيف كل شيء ونقول: التعقيد السيكلومي 120 ، ويمكن للشخص أن يفهم فقط 6. معنى هذا التقييم هو ليقول ذاتيا عندما تحتاج إلى إعادة تشكيل رمز المصدر الخاص بك ، وتقسيمها إلى أجزاء ، وتسليط الضوء على وظائف جديدة ، وما شابه ذلك. ونعم ، يمكن SonarQube القيام بذلك أيضا.
اختبارات بديلة
في عالمي ، تنطبق الاختبارات البديلة أيضًا على الاختبارات البسيطة.
التضامن هو شيء مفيد للغاية لركوب الطائرة. وليس فقط للواجهة الأمامية ، على الرغم من أنه مكتوب في جافا سكريبت. انها تسمح لك
لاختبار بيئة العمل . في السابق ، كان من الضروري إعداد تعليمات ضخمة ، مع الإشارة إلى إصدارات لغة البرمجة والمكتبات وقائمة البرامج الضرورية من أجل البدء فقط وتحديث كل شيء وما إلى ذلك. الآن يمكننا أن نقول هذا: "هنا هو جهاز الكمبيوتر الخاص بك ، وهنا هو شفرة المصدر. حتى
يمر التضامن ، لا تأتي. " في الوقت نفسه ، تكون عتبة الدخول منخفضة. يمكن لـ Solidarity أن تضع بصمات أصابع لبيئة عمل مخصصة وتتيح لك إضافة قواعد بسيطة جدًا للتحقق من صحة البرامج المثبتة ليس فقط. وهو يثير غضبكم عندما يخرجون بالكلمات: "أوه ، أنا آسف ، هناك شيء لا يصلح لي هناك ، هل يمكنك المساعدة؟ .."
حالة الاستخدام الثانية (إنها الحالة الرئيسية) هي
اختبار بيئة الإنتاج بالكلمات: "لقد مرت اختبارات الوحدة لـ CI بالتأكيد ، لكن تكوينات CI و PROD تختلف اختلافًا كبيرًا. لذلك لا توجد ضمانات ... ". هدف المكتبة بسيط للغاية: تحقيق القاعدة الأولى للتكامل المستمر: "يجب أن يتمتع كل فرد بنفس البيئة". نظيفة ومعزولة بحيث لا توجد أي آثار جانبية ، حسنا ، أو على الأقل بحيث يكون هناك أقل منها ... من أحاول خداع؟
استدعاء API
يحدث أن ينقسم المطورين إلى عدة فرق - بعضهم يكتب واجهة أمامية ، والبعض الآخر يكتب خلفية. وضع خيالي لا يمكن أن يكون في فريق حقيقي: كل شيء يعمل بالأمس ، واليوم بعد إصدارين - الأمامي والخلفي - كل شيء قد حدث. على من يقع اللوم؟ أنا كشخص ذي خبرة خلفية في البداية ، أقول دائمًا: الواجهة الأمامية.
الأمر بسيط ، لقد افسدوا مكان ما ، كما هو الحال دائمًا. عند نقطة واحدة ، يأتي بائعو الواجهة الأمامية ويقولون: "هنا نقرأ المنشور
بالرجوع إليه ، وراجعنا الدليل
وتعلمنا كيف نلقي REST API . ولن تصدق أن الأمر قد تغير ... " بشكل عام ، إذا لم تكن صداقتك الخلفية أصدقاء لـ Swagger أو openAPI أو غيرها من الحلول المماثلة - فتستحق ملاحظة.
شبيبة الأداء
وأخيرا ، اختبار أداء JS.
لا أحد يختبر أداء JS باستثناء صانعي المتصفح. كقاعدة عامة ، يستخدمون جميع
Benchmark.js . "أوه ، لقد شحذنا مستكشفنا لمدة 18 عامًا حتى يعرض الجهاز اللوحي بمليار لكل مليار بشكل أسرع من Chrome." الذي يحتاج مثل هذا الجهاز اللوحي على الإطلاق؟
إذا كنت تريد إجراء اختبارات الأداء ، فمن الأفضل أن تسير في الاتجاه الآخر: اختبار من طرف إلى طرف ومشاهدة كيفية عمله. يشكل المستخدم تصوراً لكيفية عمل التطبيق ككل ،
ولا يهتم المستخدم بأن هذه مشاكل في الجانب الخلفي.قصة الحرب رقم 1
الآن مثال من الحياة. بطريقة ما يأتي الرؤساء إلينا ويقولون: "أمامك يعمل بشكل سيء للغاية ، بالكاد يتم التحميل. يجب عمل شيء ما مع الأداء ، فالناس يشكون ". نعتقد: الآن سيكون أمامنا أسبوعين لأداء التوليف ، واختيار السجلات ،
لماذا قمت بالتحديث ، واختيار اهتزاز الأشجار ، وتقطيع كل شيء إلى أجزاء من خلال التحميل الديناميكي ... ماذا لو لم يتم الإرهاق ، فسنقطع الأمر بالكامل أو سنزيد الأمر سوءًا؟ هناك حاجة إلى حل بديل.
نفتح المتصفح ، انظر: 7.5 ميغابايت ، 2 ثانية ، كل شيء على ما يرام.
ضع Nginx GZip:
Nginx لديه القدرة على ضبط نسبة الضغط ، دعنا نجرب:
النمو - 25 ٪ من الإنتاجية. توقف مبكرا. ألقِ نظرة على شعار المصمم الصغير في الزاوية. يبقى جميلاً للغاية ، حتى لو تمدد ، لكن لماذا نحتاجه؟
إليك ما حصلت عليه بعد تحسين صورة واحدة. يمكنك تقييم وزن الشعار بنفسك. أخيرًا ، نأتي إلى العميل ونقول: "التنزيل الأول ليس بنفس أهمية التنزيل الثاني. وتمكين التخزين المؤقت القسري:
... الجميع سعداء ، الكل مبتهج! " باستثناء المستخدم ، بالطبع.
نتيجة لذلك ، قررنا إجراء تدقيق الحجم في كثير من الأحيان.
Gzip ، الخطوط ، الصور ، الأنماط - تلك الأماكن التي نادراً ما ينظر إليها أي شخص ، ولكن هناك العديد من الفوائد.
Madge و updtrJS
الخطوة التالية:
تدقيق التبعية .
Madge هو الشيء الذي يحلل الكود ويقول: هنا صف وما يرتبط به من كذا وما إلى ذلك ، إلخ. إذا مر كل شيء بعنصر واحد وانكسر ، سيكون هناك القليل من السعادة. Madge هي أداة تصوير رائعة ، ولكنها مناسبة فقط للاستكشاف اليدوي. يحتوي هذا الخيار ، التعميم ، الذي يبحث عن كل
التبعيات الدورية في مشروعك . إذا كان هناك أي شيء ، فهذا أمر سيئ ، إن لم يكن ، فهو لم يكتب بعد.
يتم حل الألم من الأطر القديمة والمكتبات تقريبا مع
updtrJS .
هل لديك 70 ألف سطر من الكود؟ هل تحاول الانتقال من الرد الثالث عشر إلى السادس عشر؟
لن يساعدك Updtr في التحرك ، لكنه سيساعدك في معرفة أي إصدارات المكتبات يمكنك الانتقال إليها دون
عواقب وخيمة . بالإضافة إلى ذلك ، يسمح للمطورين بالبقاء في الاتجاه ويساعد في الحفاظ على التبعيات الحديثة. إذا كان لديك تغطية اختبار جيدة ، أوصي.
أنواع ثابتة
استخدم الكتابة الساكنة JS ، لأن الكتابة الديناميكية
JS ليست ميزة على الإطلاق ، إنها هاوية. التدفق ، typeScript ، reasonML ...
اختبار الفوضى
إن جوهر اختبار الفوضى بسيط: ابدأ المتصفح وابدأ بتدفق كل شيء مدسوس ، وأدخل كل شيء تم إدخاله في جميع الحقول ، وما إلى ذلك. حتى يكسر. Amazon, exceptions . , « , ». , . :
Gremlin.com Chaos Monkey .
React — 16- , componentDidCatch. , exception, . .
Naughty String , , . , « », internal server error, ?
War Story #2
– . . def generateRandomPostfix(String prefix) { return prefix + "-" + Math.abs(new Random().nextInt()).toString() } def "testCorrectRandomPostfix"(){ given: def prefix = "ASD" when: def result = generateRandomPostfix(prefix) then: result?.matches(/[a-zA-Z]++-[0-9]++/) }
. . , .
. ASD, , . . ( , groovy). Java integer 1 integer. integer integer — .
, . . ? «+» fromX. , - , XML .
.
.
TestCheck.JS — . , , . —
Flow-To-Gen : Flow , .
check( property( gen.int, gen.int, (a, b) => a + b >= a && a + b >= b ) )
{ result: false, failingSize: 2, numTests: 3, fail: [ 2, -1 ], shrunk: { totalNodesVisited: 2, depth: 1, result: false, smallest: [ 0, -1 ] } }
TestCheck « », . , . , , : 0 -1. 2 -1, , . !
. . , . , ? -? permission'? ? , , , , .
3rd party failures . „ “ — .
Production-
production 16- React :
ErrorCeption HoneyBadger (
Sentry ). ,
.Optimizely /-. , , , , , .
Out of the box
JS — . , JavaScript. —
validator.w3.org/checklink . , , , , .
, , .
Achecker.ca/checker .
Webpagetest.org — , .
Tools.pingdom.com — .
www.w3.org/WAI/ER/tools .
. . , Jenkins Multibranch Plugin, - -. -, (« , »), nightly-, - regress, full regress, smart regress ..
— , , , , . , , , .
, , . .