تغطية الاختبار في Flutter ، كيف تعرف ما الذي اختبرته فعلًا وما الذي لم تختبره بعد

هل تذكّر شعورك بعد كتابة عشرات الاختبارات في مشروعك، ثم يتسلل إليك سؤال صغير:

“هل اختبرت فعلاً كل شيء؟ أم أن هناك أجزاء في الكود لم تمر عليها أي حالة اختبار؟”

هذا هو السؤال الذي تجيب عنه تغطية الاختبار (Test Coverage) — الأداة التي تُريك بالأرقام والرسوم إلى أي مدى اختباراتك تلمس أجزاء الكود.
في هذا المقال سنكتشف كيف تحسبها، كيف تحسنها، ومتى لا يجب أن تطاردها!

ما هي تغطية الاختبار؟

ببساطة، تغطية الاختبار هي النسبة المئوية من كود مشروعك الذي تم تشغيله أثناء تنفيذ الاختبارات.
فإذا كان لديك 100 دالة، ومرت الاختبارات على 80 منها، فالتغطية لديك 80٪.

لكن الأهم من الرقم نفسه هو فهم ما تغطيه وما لا تغطيه.
فقد تكون لديك تغطية 90٪ ولكن الجزء الأهم في التطبيق غير مختبَر.

✨ الهدف ليس “الوصول إلى 100٪” بل “اختبار ما يهم فعلاً”.

كيف تحسب التغطية في Flutter

Flutter يجعل قياس تغطية الاختبار سهلًا جدًا.
كل ما تحتاجه هو تشغيل هذا الأمر في الطرفية:

flutter test --coverage

سيُنشئ Flutter ملفًا باسم:

coverage/lcov.info

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

عرض النتيجة بطريقة رسومية

الأرقام وحدها لا تكفي، لذلك نستخدم أداة مثل lcov لعرض تقرير مرئي:

على أنظمة Linux أو macOS:

1. تأكد من تثبيت lcov: brew install lcov
2. ثم أنشئ تقرير HTML: genhtml coverage/lcov.info -o coverage/html
3. افتح التقرير في المتصفح: open coverage/html/index.html

🎉 الآن سترى لوحة جميلة تُظهر التغطية لكل ملف بلون أخضر (مختبَر) وأحمر (غير مختبَر).

فهم نتائج التغطية

عادة يظهر التقرير بهذا الشكل:

من هذا الجدول، يتضح أن ملف api_client.dart يحتاج إلى اهتمام خاص — ربما لأننا لم نكتب اختبارات للكود الذي يتعامل مع API.

كيف تزيد من تغطية الاختبار

1. ابدأ من المناطق الحساسة في الكود.
   ركّز على الدوال التي تتعامل مع بيانات المستخدم، أو العمليات الحرجة مثل الدفع والتسجيل.
2. استخدم المحاكاة (Mocking) لاختبار الأكواد التي تعتمد على الإنترنت أو الأجهزة.
3. اختبر الحالات السلبية (Negative Cases):
   مثل الأخطاء أو المدخلات غير الصالحة، فهي تزيد من نسبة التغطية وجودة الكود معًا.
4. اختبر الكود الشرطي:
   أي جملة if أو switch أو try/catch لم تُختبر = ثغرة غير مكتشفة محتملة.
5. ادمج التغطية مع CI/CD لتراقبها تلقائيًا مع كل تحديث.

دمج تغطية الاختبار مع CI/CD

يمكنك جعل GitHub Actions أو Codemagic يولّد تقارير تغطية آليًا مع كل عملية دمج.
مثلاً في GitHub Actions:

- name: اختبار مع تغطية
  run: flutter test --coverage

- name: توليد تقرير تغطية HTML
  run: genhtml coverage/lcov.info -o coverage/html

- name: رفع التقرير كملف Artifact
  uses: actions/upload-artifact@v3
  with:
    name: coverage-report
    path: coverage/html

بهذا الشكل، ستحصل على تقرير التغطية مباشرة داخل صفحة الـ Pull Request. ✅

هل يجب أن تكون التغطية 100٪؟

ليس بالضرورة.
تغطية 100٪ لا تعني بالضرورة أن الكود آمن تمامًا — فقد تكون اختباراتك سطحية.
وفي المقابل، تغطية 70٪ قد تكون ممتازة إذا كانت تغطي الأجزاء الأكثر أهمية.

✨ الجودة لا تُقاس بالكم، بل بالمناطق التي اخترت تغطيتها.

مقارنة سريعة بين الأنواع

لذلك احرص على أن يكون لديك مزيج متوازن من الأنواع الثلاثة للحصول على تغطية قوية ومفيدة.

نصائح إضافية لرفع الجودة مع التغطية

• اجعل التغطية تذكيرًا لا غاية.
• لا تكتب اختبارات “مزيفة” فقط لرفع الرقم.
• استخدم أدوات مثل Codecov أو Coveralls لعرض التغطية في لوحات تفاعلية.
• استمر في مراقبة التغطية عبر الإصدارات لتعرف إن كان أحد التحديثات قد كسرها.

الخلاصة

تغطية الاختبار ليست مجرد رقم تضعه في التقرير — بل هي مرآة تعكس نضج مشروعك وجودة اختباراتك.
كلما فهمت ما يغطيه الاختبار وما لا يغطيه، كلما اقتربت خطوة من تطبيق خالٍ من المفاجآت.

ابدأ بقياس التغطية اليوم، واجعلها جزءًا من عملية التطوير المستمرة لديك.

✨ تذكّر: “ما لا يُقاس لا يُحسَّن” — وتغطية الاختبار هي المقياس الأول لتحسين جودة كودك.