شرح
تتحدث المقالة عن شكل الاختبارات غير التقليدية ، ولكنها مفيدة ، كما تلخص نتائج سبع سنوات من العمل في تطوير الاختبارات.
لماذا تحتاج إلى اختبارات المكونات؟
بعد كل شيء ، هناك ، على سبيل المثال ، اختبارات الوحدة التي تختبر بالتفصيل فضلات المكونات. يتحققون تمامًا من أن المكون يعمل وفقًا لنية المطور. ولكن غالبًا ما يكون هذا فحصًا للأزرار ، وليس كيف تجلس البدلة ككل. وليس دائمًا السلوك الذي يتخذه المبرمج يتزامن مع ما يريده العميل.
وهناك ، على سبيل المثال ، اختبارات القبول. ويزيلون كل هذه العيوب. ولكن ، للأسف ، يقدمون أخرى جديدة. فهي بطيئة ، وغير مستقرة في كثير من الأحيان ، وعادة ما يتم ترويضها. ومع ذلك ، فهي تشير فقط إلى وجود مشكلة ، ولكن لا تقوم بتوطينها.
من الواضح أن الحاجة تنشأ إلى اختبارات وسيطة ، والتي ستكون الوسط الذهبي بين اختبارات الوحدة والقبول. قد تكون هذه الأرض الوسطى اختبارات مكون.
ما هي اختبارات المكونات؟
هذه اختبارات لواجهة برمجة التطبيقات للمكون العام. وفقًا لذلك ، تتم كتابتها بنفس لغة المكون. هدف الاختبار:
- التحقق من امتثال المكونات لعقودك
- تحقق من الامتثال
هذا الأخير مهم بشكل خاص منذ ذلك الحين عادةً ما تتم كتابة اختبارات الوحدات بناءً على توقعات المطور ، ولكن هنا تحتاج إلى التحقق من توقعات العملاء.
من الواضح أن اختبارات المكونات تكون منطقية عندما يكون لديك مكونات مخصصة مع واجهة واسعة النطاق. على سبيل المثال ، مكتبة ديناميكية أو كائن COM. ثم ستعطي اختبارات المكونات أقصى تأثير.
إيجابيات اختبارات k:
- أعط الاستقرار للتنمية. من الواضح أن الفحص الشامل للواجهات العامة يسمح لك بالحفاظ على المكون بشكل أكثر أو أقل كفاءة.
- توطين المشاكل بدقة. حتى إذا كان اختبار المكون نفسه عامًا تمامًا ، فيمكن دائمًا تصحيحه بعمق ، والوصول بسرعة إلى رمز المعركة. في هذه الحالة ، ستكون بيئة الاختبار في الحد الأدنى ويتم تكوينها تلقائيًا.
- تسريع التنمية مع عدد حرج من المطورين. من المعروف أن المبرمجين مثل الخيول. إذا سحب أحد الخيول عربة بسعة 1 لتر. ق ، ثم يتم سحب ثمانية خيول بسعة حوالي 4 لترات فقط. ق ولا تؤدي إضافة مطور آخر إلى الفريق (خاصة في نهاية المشروع) في كثير من الأحيان إلى التسارع فحسب ، بل يؤدي أيضًا إلى إبطائه. في حين أن إضافة مطور اختبار مكون هي دائمًا ميزة إضافية ، لأنها تعمل بشكل مستقل نسبيًا عن الفريق: فهي تقوم بالاختبارات (الخارجية بشكل أساسي) ، وتسريع بناء البناء ، وتحسن ملفات التجميع ، وما إلى ذلك.
- وضح (ثم تحقق) من متطلبات العميل. نظرًا لأن مطور اختبارات المكونات لا يرتبط بالتنفيذ ، فهو أقل تأثرًا بتأثير "أعرف كيف أفعل ذلك بنفسي". في حالة وجود شرط غامض ، يميل المطور العادي إلى القيام بذلك بشكل ملائم (أكثر إثارة للاهتمام وأسرع وأسهل). بينما يميل المطور ct في هذه الحالة إلى تحديد ما هو متوقع تمامًا من قبل العميل.
- مستقر نسبيًا وسريعًا نسبيًا (بالمقارنة مع الاختبارات اليدوية والاختبارات الآلية من خلال واجهة المستخدم).
سلبيات الاختبارات K:
- حان وقت التطوير والدعم. من الواضح أن إصدار ألفا للمنتج ، إذا قضى جزءًا من الوقت في كتابة اختبارات المكونات ، سيظهر لاحقًا. هل سيكون هناك مكسب بشكل عام؟ هل سيكون هناك إصدار عاجل؟ هذا سؤال جيد. رأيي: عند التطوير باستخدام اختبارات المكونات ، سيتم إصدار الإصدار في نفس الوقت تقريبًا. ولكن - مع شائعات أقل وأكثر قابلية للتنبؤ بها من حيث الوقت. سيزداد وقت التطوير بشكل طبيعي ، وسيتم تقليل وقت إصلاح الأخطاء والتثبيت. نظرًا لأن الجزء الثاني لا يمكن التنبؤ به كثيرًا ، فإن تخفيضه سيكون له تأثير مفيد على كمية المعالجة والمتاعب. ومع ذلك ، هذه هي تجربتي فقط ، وقد يختلف الواقع. من الممكن أن يتم تخصيص الوقت المخصص لاختبارات المكونات بشكل غير لائق على تكرار اختبارات الوحدة الحالية.
- تبادلية أقل. يزيد فصل الأدوار من الكفاءة ، ولكنه يقلل من التبادلية. نادرًا ما يرغب المطورون في التعمق في اختبارات المكونات ، والتي يمكن أن يكون لها (أو تحاكي) بيئة معقدة إلى حد ما. مطورو اختبارات المكونات بعيدون عن معرفة رمز المعركة جيدًا بحيث يمكن تحريره بسهولة.
- الازدواجية المزعجة. مع اختبارات الوحدة الجيدة ، غالبًا ما تتحول اختبارات المكونات إلى فائض في الغالب. هذا مزعج ويتساءل عن حاجتهم. يساعد تنسيق خطط الوحدة واختبار المكونات ، ولكن عادة لا يتم التخلص من الازدواجية بشكل كامل.
- الحاجة إلى متابعة سير العمل الصحيح. عند استلام المتطلبات ، يجب وضع المهمة في وقت واحد على مطور ومطور الاختبارات. ثم ينهون العمل في نفس الوقت تقريبًا. يتم تشغيل المكون من خلال الاختبارات ، ويتم اكتشاف الأخطاء وتصحيحها بسرعة ، ويتم استخدام منتج نهائي تقريبًا للخروج. في هذه الحالة ، يتم زيادة فوائد اختبارات المكونات. ولكن غالبًا ما يحدث أن المواعيد النهائية مدمنة لفترة طويلة ، ويتم التخلي عنها جميعًا لكتابة التعليمات البرمجية فقط ، ويتم إرسال المكون إلى الاختبار اليدوي بدون اختبارات. وعندها فقط يدعون مطور الاختبارات - يقولون أنه ليس من الجيد أن يتم إصدار الشفرة بدون الاختبارات ، يجب أن نضيفها. في هذه الحالة ، تكون معظم الأخطاء عبارة عن أجهزة اختبار يدوية ، ويقوم المطورون بإجراء التصحيحات بشكل أعمى (أو اختبار التعديلات يدويًا بأنفسهم) ، والاختبارات المكتوبة بعد الحقيقة لا تجد سوى عدد صغير من الأخطاء (مما يؤثر سلبًا على معنوية كاتبهم). مثل هذا الاستخدام لاختبارات المكونات عديم الفائدة في أحسن الأحوال ، ومن الصعب التأمين ضده.
- هناك عدد قليل من الناس المناسبين. يجب أن يكون مطور اختبارات المكونات ، من ناحية ، قادرًا على كتابة التعليمات البرمجية بلغة المكون (وهذا ، على سبيل المثال ، C ++). علاوة على ذلك ، إذا كانت بيئة تشغيل المكون واسعة النطاق ، فقد يكون الرمز معقدًا للغاية. ومن ناحية أخرى ، كن قادرًا على اختبار عمل شخص آخر بدقة. لا يوجد الكثير من هؤلاء الأشخاص ، وعادة ما يذهبون مباشرة إلى المطورين. ولكن لا يزال هناك مثل هؤلاء الناس ، والجزء التالي عنهم.
الملخص 1
اختبارات المكونات جيدة ، ولكن فقط إذا كانت لديك جميع الشروط لها: واجهة برمجة تطبيقات عامة واسعة ، وسير العمل المناسب ، والأشخاص المناسبين في الفريق.
ماذا يعني أن تكون SDET؟
من الواضح أن SDET - مهندس تطوير البرمجيات في الاختبار هو مرشح مثالي لكتابة اختبارات المكونات. إنه يعرف كيف يكتب الشفرة ويعرف كيف يفكر في الاختبارات. كما يوفر رأيًا ثانيًا ، مما يحسن أيضًا جودة الاختبارات والتعليمات البرمجية. كل هذا يبدو مشوقًا ومغريًا - ربما تريد بالفعل أن تكون واحدًا. هنا سأخبرك باختصار كيف يختلف عمل SDET عن عمل مطور خالص.
مزايا العمل مع SDET:
- كود جديد. دائما تقريبا ، يكتب SDET الاختبارات من نقطة الصفر. وكثيراً ما تكون البيئة مكتوبة من الصفر. إنه لطيف للغاية ويعطي مجالًا كبيرًا للإبداع.
- اعتماد منخفض على الرمز القديم. بغض النظر عن مدى فظاعة رمز المعركة ، يمكن إجراء الاختبارات عليه بكفاءة وجمال. بالطبع ، الكود ضعيف التصميم يولد اختبارات قبيحة ، ولكن لا يزال من الممكن جعلها مرتبة من حيث الحجم أفضل من الكود نفسه.
- إعادة بيع ديون أكثر تواترا. التغييرات في الاختبارات أقل خطورة ، لذلك ، يتم الاتفاق عليها في كثير من الأحيان. هذه فرصة جيدة للعمل على الأخطاء وممارسة كتابة التعليمات البرمجية النظيفة من خلال إعادة الهيكلة.
- تنمية التفكير النقدي. الاختبارات الذاتية هي بحث مثير للاهتمام عن كيفية كسر رمز شخص آخر. علاوة على ذلك ، ليس البحث غبيًا ، ولا يجلس بدسًا ، ولكن بمساعدة المنطق والاندماج والقدرة على رؤية نقاط الضعف. بالإضافة إلى ذلك ، بمجرد إنشاء شيك سيستمر في العمل من أجلك باستمرار.
- تطوير القدرة على اختبار الكود. في التدريب القتالي اليدوي ، غالبًا ما يعطون كلمات تمهيدية: "الآن نحن نعمل فقط بأقدامنا ؛ الآن نحن نعمل فقط مع رؤوسنا". يسمح لك استخدام آلية واحدة فقط (في حالتنا ، الاختبارات الذاتية) بشحذها إلى إتقانها.
- عدد أقل من الشائعات. يتم سحب SDETs أقل بكثير لعطلة نهاية الأسبوع. ليس عليهم الذهاب للعمل على وجه السرعة لإصلاح الخلل الحرج. حسنًا ، لديهم فرصة أقل بكثير لارتكاب خطأ جسيم.
سلبيات العمل مع SDET:
- تعقيد ترميز منخفض. عادة ما يكون رمز الاختبار أبسط من رمز المعركة. الشروط المسبقة ، استدعاء رمز المعركة ، الشروط اللاحقة - وهكذا لكل اختبار. رمز إنشاء البيئة أكثر تعقيدًا ، ولكنه لا يزال لا يصل إلى القتال. اختيار الخوارزميات المثلى ، وتصميم هياكل البيانات المعقدة ، وبناء التسلسل الهرمي للفئة - عادة ما يمر كل هذا من قبل مطور الاختبار.
- الخبرة تزداد ببطء . تنوع وتعقيد المواقف التي يقع فيها مطور الاختبار أقل بكثير. فشل خط التجميع ، الاختبارات الحمراء ، في بعض الأحيان مقالب - هذه هي المجموعة الرئيسية التي عادة ما يتعين عليك العمل معها. يواجه المطور المزيد من المشاكل: بدءًا من اختلافات الربط والتجميع ، والمتابعة مع وجود خلل في عميل معين ومكبات متقنة ، وتنتهي بالبحث عن الأخطاء في المترجم ومكتبات الطرف الثالث. وليس فقط ...
- فرق كبير في أسلوب الاختبار مع المطورين. عادة ، تفضل SDET الاختبارات المعبرة المضغوطة التي تسمح لك بإنشاء بيئة معقدة في بضعة أسطر فقط ، وتكون الفحوص الذرية في النمط متساوية / غير متساوية (أي أنه تم استيفاء المتطلبات أم لا). في بعض الأحيان يتعلق الأمر بـ DSL. ببساطة ، يفضل المطورون الاختبارات مع تحسين البيئة والعديد من الاختبارات لمختلف جوانب سلوك البرنامج ، مما يؤدي إلى اختبارات متعددة الخطوط تمامًا. في بعض الأحيان يتعلق الأمر بنسخ ولصق (والذي حتى أفضل المطورين لا يعتبرون الخطيئة في هذه الحالة). هنا يمكنك أن تناقش لفترة طويلة أفضل طريقة أو حتى كتابة مقال منفصل ، ولكن الحقيقة هي أنه عندما يحاول المطور تعديل اختبارات SDET (أو العكس) ، فإن هذا غالبًا ما يؤدي إلى مناقشات طويلة وغير فعالة.
- يوجد أدناه "الدرجة". ربما بسبب رمز أبسط ومسؤولية أقل ، ولكن في النهاية ليس مهمًا. عادة ما يكون الأمر كذلك.
- من الصعب الانتقال إلى منصب جديد. قد تحصل SDET على سؤال جيد على الجبين: لقد كنت تكتب اختبارات لفترة طويلة ، أي في الواقع ، لقد اتصلت للتو بالوظائف وقارنت النتائج - هل يمكنك كتابة رمز حقيقي؟ هل تعرف كل عيوب اللغة؟ هل قمت بحل المشاكل المعقدة؟ هل كان عليك تفكيك الحشرات أو مقالب مزخرفة؟ هل هناك أي خبرة في تعدد مؤشرات الترابط؟ هل لديك طموحات؟
الملخص 2
كشخص عمل كمطور لسنوات عديدة ، ثم ذهب إلى SDETs لعدة سنوات ، ثم عاد إلى التطوير مرة أخرى ، يمكنني أن أقول ما يلي.
أوصي بشدة بإنفاق SDET لمدة عام أو عامين على الأقل. هذه تجربة مجزية للغاية لأي مطور. لكن البقاء هناك ، في رأيي ، لا يستحق ذلك.