اختبارات في المجلدات الفرعية Go: تحليل كامل للمبتدئين

مدرب بايثون أونلاين للمبتدئين

تعلم Python بسهولة دون إرهاق نظري. حل مهام عملية مع التحقق التلقائي واكتب الكود مباشرة في المتصفح.

ابدأ الدورة

اختبارات في المجلدات الفرعية Go: حل المشكلة التي لا تذكرها الدروس التعليمية

\n\n

هل سبق لك أن كتبت اختبارات في Go وواجهت مشكلة أنها تعمل بشكل ممتاز في جذر المشروع، ولكن بمجرد نقلها إلى مجلد فرعي - كل شيء ينهار؟ مألوف؟ إذا كان الأمر كذلك - فأنت لست وحدك. سؤال "Golang tests in sub-directory" على Stack Overflow حصد آلاف المشاهدات. وهذا ليس مفاجئًا: توثيق Go يتحدث عن هذا بشكل جاف، والمطورون المبتدئون غالبًا ما يضيعون.

\n\n

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

\n\n

لماذا الاختبارات في المجلدات الفرعية مؤلمة؟

\n\n

تخيل: لديك مشروع هيكله كالتالي:

\n\n
myapp/\n├── main.go\n├── go.mod\n└── utils/\n    ├── math.go\n    └── math_test.go
\n\n

تكتب Go test في الجذر - وكل شيء يعمل. ولكن عندما تحاول تشغيل الاختبارات من مجلد utils، يشتكي Go: "package myapp/utils is not in GOROOT". خطأ مألوف؟

\n\n

المشكلة هي أن Go يعمل مع الحزم، وليس مع المجلدات. عندما تنشئ مجلدًا فرعيًا، فأنت في الواقع تنشئ حزمة جديدة. ويجب تشغيل الاختبارات فيه مع مراعاة هيكل الوحدة النمطية للمشروع. لكن دعنا نأخذ الأمر بالترتيب.

\n\n

الأساسيات: كيف يرى Go الاختبارات

\n\n

في Go، الاختبارات هي ملفات عادية باللاحقة _test.go. يمكن أن تكون موجودة:

\n
    \n
  • في نفس الحزمة (اختبارات بيضاء) - لديها وصول إلى الدوال غير المُصدرة.
  • \n
  • في حزمة منفصلة باللاحقة _test (اختبارات سوداء) - تختبر الحزمة كمستخدم خارجي.
  • \n
\n\n

عندما تضع الاختبارات في مجلد فرعي، فإنك تنشئ حزمة جديدة. على سبيل المثال، المجلد utils هو حزمة utils. ويجب أن تنتمي الاختبارات فيه إلى هذه الحزمة.

\n\n

مثال على هيكل صحيح

\n\n
myapp/\n├── go.mod\n├── main.go\n└── utils/\n    ├── math.go        // package utils\n    └── math_test.go   // package utils
\n\n

في ملف math.go:

\n
package utils\n\nfunc Add(a, b int) int {\n    return a + b\n}
\n\n

في ملف math_test.go:

\n
package utils\n\nimport "testing"\n\nfunc TestAdd(t *testing.T) {\n    result := Add(2, 3)\n    if result != 5 {\n        t.Errorf("Expected 5, got %d", result)\n    }\n}
\n\n

الآن قم بتشغيل الاختبارات من جذر المشروع:

\n
go test ./utils/
\n\n

أو من مجلد utils:

\n
cd utils\ngo test
\n\n

كل شيء يعمل! ولكن ماذا لو كان لديك هيكل أكثر تعقيدًا؟

\n\n

المجلدات الفرعية المتداخلة: أعمق مما يبدو

\n\n

لنفترض أن لديك مشروعًا بهذا الهيكل:

\n\n
myapp/\n├── go.mod\n├── main.go\n└── services/\n    ├── user/\n    │   ├── user.go\n    │   └── user_test.go\n    └── order/\n        ├── order.go\n        └── order_test.go
\n\n

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

\n\n
go test ./...
\n\n

هذا الأمر سيجد جميع الحزم في المشروع ويشغل اختباراتها. مريح جدًا لـ CI/CD!

\n\n

ماذا لو كانت الاختبارات في نفس مجلد الكود؟

\n\n

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

\n\n

الأخطاء النموذجية وحلولها

\n\n

دعنا نستعرض المشاكل الأكثر شيوعًا التي يواجهها المبتدئون عند العمل مع Golang tests in sub-directory.

\n\n

الخطأ 1: "package is not in GOROOT"

\n

السبب: تحاول تشغيل اختبار من مجلد فرعي دون تحديد الوحدة النمطية. Go لا يعرف إلى أي وحدة نمطية تنتمي الحزمة.

\n

الحل: تأكد من وجود go.mod في الجذر

المدونات

توصيات الكتب