تغطية الكود بالاختبارات في Go: المقاييس والأدوات والأمثلة العملية

تغطية الكود بالاختبارات في Go: من "العلامة الخضراء" إلى الجودة الحقيقية

في عالم تطوير Go، تبدو عبارة "لدي تغطية 95%" فخورة. لكن غالبًا ما تخفي هذه الأرقام فراغًا: تختبر الاختبارات المسار السعيد فقط، بينما تُترك الحالات الحدودية والأخطاء خارجًا. في هذه المقالة، سنفهم كيفية قياس تغطية الكود بالاختبارات في Go بشكل حقيقي، وما هي المقاييس المهمة حقًا، وما هي الأدوات التي ستساعد في تحويل الاختبار من إجراء شكلي إلى أداة قوية لمراقبة الجودة.

لن نعيد سرد الوثائق. بدلاً من ذلك، سنقدم أمثلة حية، ومزالق، ونصائح عملية لمن يكتبون بلغة Go ويريدون النوم بسلام.

لماذا مجرد 80% هو أمر سيء؟

لنفترض أن لديك دالة:

func ProcessOrder(amount float64, discount bool) (float64, error) {\n    if amount <= 0 {\n        return 0, errors.New("amount must be positive")\n    }\n    if discount {\n        amount *= 0.9\n    }\n    return amount, nil\n}

لقد كتبت اختبارًا واحدًا: ProcessOrder(100, true) → 90, nil. التغطية؟ 100% من الأسطر. لكنك لم تتحقق من حالة amount <= 0 والحالة بدون خصم. رسميًا - التغطية ممتازة. واقعيًا - الأخطاء مضمونة. لهذا السبب يجب النظر إلى مقاييس تغطية الكود بالاختبارات في Go بالتزامن مع مؤشرات أخرى.

أدوات التغطية: من البسيط إلى المعقد

1. الأداة المدمجة go test -cover

أبسط طريقة لمعرفة تغطية الكود بالاختبارات في Go هي العلامة -cover:

go test -cover ./...

المخرجات:

ok      myproject/orders    0.234s    coverage: 72.3% of statements

لكن هذا مجرد رقم إجمالي. لرؤية أي الأسطر غير مغطاة، استخدم -coverprofile:

go test -coverprofile=coverage.out ./...\ngo tool cover -html=coverage.out

سيفتح المتصفح مع تمييز: الأخضر - مغطى، الأحمر - غير مغطى. هذه هي الخطوة الأولى لفهم مقاييس التغطية في Go.

2. go tool cover: الأوضاع والفروق الدقيقة

يدعم go tool cover ثلاثة أوضاع:

\n
• set - هل تم تنفيذ السطر مرة واحدة على الأقل (الوضع الافتراضي)
\n
• count - كم مرة تم تنفيذ كل سطر
\n
• atomic - count، ولكن مع عدادات ذرية للاختبارات المتوازية
\n

لـ تحليل تغطية الاختبارات في Golang في الكود متعدد الخيوط، استخدم atomic، وإلا فإنك تخاطر بالحصول على عدادات غير صحيحة بسبب حالة السباق.

go test -covermode=atomic -coverprofile=coverage.out ./...

3. كاشف السباق - التغطية المخفية

سباقات البيانات هي واحدة من المشاكل الرئيسية في كود Go. حتى لو كانت تغطية الأسطر 100%، يمكن لكاشف السباق العثور على أخطاء لم تلاحظها الاختبارات. قم بتشغيل الاختبارات مع العلامة -race:

go test -race -cover ./...

هام: يبطئ كاشف السباق الاختبارات بمقدار 2-20 مرة، لكنه ممارسة إلزامية للوحدات الحرجة. قم بتضمينه في CI للحزم الرئيسية.

المقاييس التي تهم حقًا

نسبة تغطية الأسطر هي مجرد قمة جبل الجليد. إليك ما يجب تتبعه:

1. تغطية الفروع (branch coverage)

يحسب go test -cover القياسي الأسطر وليس الفروع. لـ تغطية الكود بالاختبارات في Go على مستوى الفروع، استخدم gocov أو go-test-coverage. مثال:

go get github.com/axw/gocov/gocov\ngocov test ./... | gocov report

سترى ليس فقط الأسطر، ولكن أيضًا عدد الشروط غير المغطاة. على سبيل المثال، لدالة تحتوي على اثنين من if - 4 فروع، منها 2 مغطاة.

2. تغطية الطفرات (mutation testing)

الطريقة الأكثر صدقًا لتقييم جودة الاختبارات هي