يبدأ العمل مع الاختبار.

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

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

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

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



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



يعمل النموذج ، يتم حفظ البيانات بنجاح ، العميل راض. ولكن فجأة جاءت مكالمة غاضبة من العميل: "يقولون ذلك ، لقد وصل الطلب - تريد شركة المليونير شراء جميع الطوب مني ، لكن رقم الهاتف لم يرد من النموذج وكيف يمكنني الاتصال بهم الآن؟! غدا سوف تجد مورد آخر! كيف ذلك ماذا فعلت؟ إنه خطأك ... " دموع العميل و قذفه ، ناقص الأعصاب ، ناقص الثقة و ناقص الاحترام. الموقف قياسي للغاية بالنسبة للناشئين - عدم وجود أي اختبار واختبار البيانات الواردة من النموذج. يتم حل المهمة الأولى (التحقق من الصحة) بكل بساطة عن طريق إضافة قواعد التحقق من الصحة:



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



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

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

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

بادئ ذي بدء ، نحتاج إلى كتابة طريقة اختبار لملء بيانات النموذج بشكل صحيح:



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



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



الشيكات لدينا في مكان ، يمكنك تشغيل والتحقق



الكمال. تعطل تطبيقنا في 5 من أصل 5 اختبارات. هدفنا الآخر هو استكشاف طرق الاختبار التي تقوم بتعيين قيم غير صالحة على الحقول وتشكيل قواعد التحقق من صحة البيانات الواردة. المنطق مثل هذا: لا يمكن أن يكون حقل fio فارغًا ؛ الطول لا يقل عن 3 ولا يزيد عن 120 ؛ هذه سلسلة تحتوي على مجموعة من الأحرف المسموح بها في الاسم (أحرف ، وواصلات ، مسافات بادئة). نتيجة هذا المنطق في جميع المجالات:



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



وأخيرًا ، يمكننا التحقق من كيفية عمل البرنامج النصي للاختبار (أذكر أنه كان هناك 5 حالات فشل في 5 اختبارات).



كما ترون ، تم اجتياز جميع الاختبارات بنجاح وتم إدخال إدخال واحد فقط في قاعدة البيانات (حيث تم تكوين طريقة واحدة فقط للعمل بشكل صحيح).



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