الاختبارات و TDD

مقدمة إلى اختبار البرمجيات

25 دقيقة الدرس 1 من 35

مقدمة إلى اختبار البرمجيات

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

لماذا نختبر الكود؟

يوفر الاختبار فوائد عديدة تجعله جزءًا أساسيًا من تطوير البرمجيات الاحترافي:

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

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

أنواع اختبارات البرمجيات

يشمل اختبار البرمجيات أنواعًا مختلفة من الاختبارات، كل منها يخدم غرضًا مختلفًا:

1. اختبارات الوحدة (Unit Tests)

اختبار المكونات أو الوظائف الفردية بشكل منفصل. هذه هي الاختبارات الأكثر دقة.

<!-- مثال: اختبار وظيفة بسيطة -->
<script>
function add(a, b) {
    return a + b;
}

// اختبار الوحدة
test('add should sum two numbers', () => {
    expect(add(2, 3)).toBe(5);
    expect(add(-1, 1)).toBe(0);
});
</script>

2. اختبارات التكامل (Integration Tests)

اختبار كيفية عمل مكونات متعددة معًا. تتحقق من أن الأجزاء المختلفة من نظامك تتكامل بشكل صحيح.

<!-- مثال: اختبار تكامل قاعدة البيانات -->
<?php
public function test_user_can_be_saved_to_database()
{
    $user = User::create([
        'name' => 'John Doe',
        'email' => 'john@example.com'
    ]);

    $this->assertDatabaseHas('users', [
        'email' => 'john@example.com'
    ]);
}
?>

3. الاختبارات الوظيفية (Functional Tests)

اختبار ميزات كاملة أو سير عمل المستخدم من منظور المستخدم النهائي.

4. اختبارات الطرف إلى الطرف (End-to-End Tests)

اختبار تدفق التطبيق بأكمله من البداية إلى النهاية، محاكاة سيناريوهات المستخدم الحقيقية.

5. اختبارات القبول (Acceptance Tests)

التحقق من أن النظام يلبي متطلبات العمل ومقبول للمستخدمين النهائيين.

6. اختبارات الأداء (Performance Tests)

تقييم أداء النظام تحت أحمال وظروف ضغط مختلفة.

7. اختبارات الأمان (Security Tests)

تحديد نقاط الضعف والتأكد من أن التطبيق آمن ضد التهديدات.

هرم الاختبار

هرم الاختبار هو مفهوم قدمه Mike Cohn يوضح التوزيع المثالي لأنواع الاختبارات المختلفة:

        /\
       /  \  ← اختبارات E2E (قليلة)
      /────\
     / تكامل \  ← اختبارات التكامل (بعض)
    / Inte   \
   /──────────\
  /  اختبارات \  ← اختبارات الوحدة (كثيرة)
 /   الوحدة   \
/________________\

لماذا هذا الشكل؟

اختبارات الوحدة (القاعدة): اختبارات كثيرة، تنفيذ سريع، رخيصة للكتابة والصيانة، تختبر أجزاء صغيرة
اختبارات التكامل (الوسط): عدد معتدل، أبطأ من اختبارات الوحدة، تختبر تفاعلات المكونات
اختبارات E2E (القمة): اختبارات قليلة، أبطأ تنفيذ، مكلفة للصيانة، تختبر رحلات المستخدم الحرجة

أفضل ممارسة: اتبع قاعدة 70/20/10: حوالي 70% اختبارات وحدة، 20% اختبارات تكامل، و 10% اختبارات طرف إلى طرف. يوفر هذا تغطية جيدة مع الحفاظ على سرعة الاختبارات وسهولة صيانتها.

مصطلحات الاختبار الرئيسية

فهم هذه المصطلحات ضروري للتواصل الفعال حول الاختبار:

حالة الاختبار (Test Case)

سيناريو محدد يختبر جانبًا معينًا من الوظائف. يتضمن المدخلات والمخرجات المتوقعة والشروط المسبقة.

مجموعة الاختبار (Test Suite)

مجموعة من حالات الاختبار ذات الصلة المجمعة معًا.

التأكيد (Assertion)

عبارة تتحقق من صحة شرط ما. تفشل الاختبارات إذا كانت التأكيدات خاطئة.

<script>
// أمثلة على التأكيدات
expect(result).toBe(expected);
expect(array).toContain(item);
expect(value).toBeGreaterThan(10);
</script>

تغطية الاختبار (Test Coverage)

النسبة المئوية للكود الذي يتم تنفيذه بواسطة اختباراتك. بينما لا تكون التغطية 100% ضرورية دائمًا، استهدف تغطية عالية للمسارات الحرجة.

اختبار الانحدار (Regression Testing)

تشغيل الاختبارات للتأكد من أن التغييرات الجديدة لم تكسر الوظائف الموجودة.

تركيبة الاختبار (Test Fixture)

الحالة الثابتة المستخدمة كخط أساس لتشغيل الاختبارات، مما يضمن الاتساق.

Mock/Stub/Spy

بدائل الاختبار المستخدمة لاستبدال الكائنات الحقيقية في الاختبارات:

Mock: يحاكي سلوك الكائن ويتحقق من التفاعلات
Stub: يوفر استجابات محددة مسبقًا لاستدعاءات الطرق
Spy: يسجل معلومات حول كيفية استدعائه

الإعداد والتنظيف (Setup and Teardown)

الكود الذي يعمل قبل وبعد الاختبارات لإعداد البيئة وتنظيف الموارد.

<script>
describe('User Authentication', () => {
    beforeEach(() => {
        // الإعداد: يعمل قبل كل اختبار
        database.clear();
    });

    afterEach(() => {
        // التنظيف: يعمل بعد كل اختبار
        database.disconnect();
    });

    test('user can login', () => {
        // كود الاختبار هنا
    });
});
</script>

عقلية الاختبار

يتطلب الاختبار الفعال العقلية الصحيحة:

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

خطأ شائع: لا تكتب اختبارات فقط لتحقيق أرقام تغطية عالية. ركز على اختبار السلوكيات المهمة والحالات الحدية. الاختبارات الهادفة أفضل من الاختبارات العديدة غير الهادفة.

متى نكتب الاختبارات

هناك طرق مختلفة لتوقيت كتابة الاختبارات:

التطوير ثم الاختبار

كتابة الكود أولاً، ثم كتابة الاختبارات. هذا شائع لكن يمكن أن يؤدي إلى كود يصعب اختباره.

التطوير الموجه بالاختبار (TDD)

كتابة الاختبارات قبل كتابة الكود الفعلي. هذا النهج (المغطى في الدرس 3) يضمن أن الكود الخاص بك قابل للاختبار منذ البداية.

التطوير الموجه بالسلوك (BDD)

مشابه لـ TDD لكن يركز على سلوك الأعمال ويستخدم لغة طبيعية أكثر لأوصاف الاختبار.

أفضل ممارسات الاختبار

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

نصيحة احترافية: اتبع مبادئ FIRST للاختبارات الجيدة: Sريعة، مSتقلة، Qابلة للتكرار، ذاتية الTحقق، في الوقت الMناسب.

عائد الاستثمار في الاختبار

بينما يتطلب الاختبار استثمارًا أوليًا، فإنه يوفر عوائد بطرق متعددة:

تقليل وقت التصحيح
أخطاء إنتاج أقل
إعادة هيكلة وصيانة أسهل
إنتاجية فريق أفضل
تكاليف دعم أقل
تحسين رضا العملاء

تمرين

أسئلة للتفكير:

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

الخلاصة

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

النقاط الرئيسية:

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