الصورة العامة لاختبار الوحدة

هذا ليس دليلاً حول الأحرف التي تحتاج إلى إدخالها في محرر الرمز للحصول على اختبارات الوحدة. هذا غذاء للعقل ، والذي يجب استهلاكه قبل اتخاذ هذه الإجراءات.

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

ما هو الاختبار؟

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

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

إليكم نبذة تاريخية عن أن أصبح اختبارًا:

• 1822 - محرك الفرق (تشارلز باباج).
• 1843 - محرك تحليلي (Ada Lovelace).
• 1878 - قدم إديسون مصطلح "الشوائب".
• 1957 - اختبار وتصحيح البرامج (تشارلز بيكر).
• 1958 - أول فريق اختبار برمجيات (جيرالد واينبرغ).
• 1968 - أزمة الأزمات (فريدريش باور).
• 1970s - نموذج الشلال ، النموذج العلائقي ، التحلل ، التحليل النقدي ( تجول ) ، تصميم وفحص الكود ، الجودة والمقاييس ، أنماط التصميم.
• 1980s - تحليل CRUD ، بنية النظام ، الاختبار الذاتي ، النموذج V ، الموثوقية ، تكلفة الجودة ، طرق الاستخدام ، أنماط تصميم OOP.
• 1990 - سكروم ، اختبار قابلية الاستخدام ، MoSCoW ، الاختبار التجريبي ، أتمتة البرمجيات واختبارها.

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

• ... - تصحيح 1956
• 1957-1978 مظاهرة
• 1979 - 1982 تدمير
• 1983 - 1987 تقدير
• 1988 - ... الوقاية

لذلك ، يعد اختبار الوحدة ضروريًا لمنع الاختلافات بين المشروع والتنفيذ.

ما هو الاختبار حقا؟

هناك تصنيفات مختلفة لاختبار البرمجيات. لفهم مكان اختبار الوحدة بشكل أفضل ، سأذكر فقط الأساليب الأكثر انتشارًا.

الاختبارات هي: ثابت وديناميكي ، "صندوق" (صندوق أبيض ، صندوق أسود ، صندوق رمادي) ، المستويات والأنواع. يستخدم كل نهج معايير تصنيف مختلفة.

اختبار ثابت وديناميكي

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

يتطلب الاختبار الديناميكي للحصول على النتائج الصحيحة تنفيذ التعليمات البرمجية. على سبيل المثال ، لاختبارات الوحدة والتكامل والنظام والقبول وغيرها من الاختبارات. أي أن الاختبار يتم باستخدام البيانات الديناميكية والمدخلات والمخرجات.

نهج الصندوق

وفقًا لهذا النهج ، تنقسم جميع اختبارات البرمجيات إلى ثلاثة أنواع من الصناديق:

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

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

مستويات الاختبار

يختلف عددهم ، عادة ما يتراوح بين 4 و 6 ، وكلهم مفيدون. قد تختلف الأسماء أيضًا ، اعتمادًا على الثقافة التي تتبناها الشركة ، قد تعرف اختبارات "التكامل" على أنها "وظيفية" ، واختبارات "النظام" على أنها "آلية" ، وما إلى ذلك. من أجل البساطة ، سأصف 5 مستويات:

1. اختبار الوحدة
2. اختبار التكامل.
3. اختبار واجهات المكونات.
4. اختبار النظام.
5. اختبار القبول التشغيلي.

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

أنواع الاختبار

يمكن أيضًا تقسيم كل نوع من أنواع الاختبارات ، بغض النظر عن مستواه ، إلى أنواع أخرى. هناك أكثر من 20 نوعًا شائعًا. الأكثر شيوعًا:

• اختبار الانحدار .
• اختبار القبول.
• اختبار الدخان
• شوفان
• اختبار مدمر .
• اختبار الأداء.
• الاختبار المستمر .
• اختبار قابلية الاستخدام.
• اختبار الأمان.

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

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

ما هو اختبار الوحدة؟

نموذج V عبارة عن تمثيل رسومي للمستويات والأنواع والغرض منها أعلاه في دورة حياة تطوير البرامج.



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

وهذا عادل. اختبارات الوحدة لها الكثير من المزايا. هم:

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

ومع ذلك ، هناك بعض القيود التي فكرت فيها ، ربما عند قراءة هذه القائمة:

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

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

كثيرا ما ناقشت مع الزملاء والعملاء ما هو اختبار الوحدة الجيد. قال:

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

لأولئك الذين ابتسموا بعد قراءة "آلي": لم أقصد دمج PHPUnit أو JUnit في خطوط الأنابيب CI. الهدف هو أنه إذا قمت بتغيير الرمز ، احفظه ولا تعرف ما إذا كانت الوحدات تجتاز اختباراتها ، فهي ليست آلية ، ولكن يجب ذلك. الخيار الفائز هو تتبع الملفات.

ما الذي يجب إخضاعه لاختبار الوحدة؟

في الأنظمة العادية ، يجب كتابة اختبارات الوحدة من أجل:

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

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

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

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

هذا النهج يجعل اختبار الوحدة أسهل للفهم. تحليل كل طريقة على حدة. يمكن لمقدمي البيانات المساعدة في تحديد المدخلات والمخرجات لأي سيناريو قد يتبادر إلى ذهنك ، لذا بغض النظر عما يحدث ، ستعرف ما يمكن توقعه.

ما لا يلزم اختباره

من الصعب تحديد أنك لست بحاجة إلى الاختبار. حاولت تجميع قائمة بالعناصر التي لا تحتاج إلى الخضوع لاختبار الوحدة:

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

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

كيف تكتب اختبارات الوحدة؟

• اكتب الرمز المناسب لاختبار الوحدة ، ثم اختبره.
• اكتب الرمز المناسب لاختبار الوحدة ، ثم اختبره.
• اكتب الرمز المناسب لاختبار الوحدة ، ثم اختبره.

إذا لم يكن "ثم اختبره " كافيًا ، فإن موقع laracasts.com لديه مقاطع فيديو جيدة جدًا حول اختبار وحدة PHP. هناك الكثير من المواقع المخصصة لنفس المهمة بلغات أخرى. لا أرى أي سبب لشرح كيفية إجراء اختبار الوحدة ، لأن الأدوات تتغير بسرعة كبيرة ، وعندما تقرأ هذا النص ، يمكنني التبديل من PHPUnit إلى Kahlan. أم لا. من يدري.

ولكن الإجابة على السؤال الأول (كيفية كتابة رمز مناسب لاختبار الوحدة) أسهل بكثير ، ومن غير المحتمل أن يتغير الوضع كثيرًا بمرور الوقت:

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

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

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