الوحدة مقابل اختبارات التكامل

1) لماذا التمييز بين أنواع الاختبارات

التحضير السليم للاختبارات يجعل التطوير قابلاً للتنبؤ: الوحدة تصطاد العيوب المنطقية بسرعة وبتكلفة زهيدة ؛ يتحقق التكامل من حزم الوحدات والنقل الحقيقي و "الغراء. "معًا، يقللون من الانحدار ويسرعون الإطلاقات.

2) التعاريف والحدود

اختبار الوحدة

اختبار وحدة صغيرة من السلوك (وظيفة، فئة، حالة استخدام) في عزلة.
يتم استبدال التبعيات الخارجية (وهمية/كعب/مزيفة).
سريع (السيدة عشرات الآنسة)، حتمية.

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

يتحقق من تفاعل العديد من المكونات الحقيقية: قاعدة البيانات، الوسيط (Kafka/RabbitMQ)، HTTP/gRPC، نظام الملفات، ذاكرة التخزين المؤقت.
الحد الأدنى من الموك، بروتوكولات حقيقية.
أبطأ (مئات الثواني)، وأكثر تكلفة في الدعم.

3) اختبار الهرم (وليس القرن الجليدي)

المؤسسة: الوحدة (70-80٪ في العدد) - رخيصة، سريعة.
الطبقة الوسطى: التكامل/المكون (15-25٪) - المسارات والعقود الحرجة.
الأعلى: E2E/UX/Exploratory (5-10٪) - الحد الأدنى الكافي.
على الجانبين: التحليل الثابت/الوبر/اختبار النوع واختبار الطفرة كمضخمات للجودة.

4) ما الذي يجب تقديمه للوحدة وما هو التكامل

5) البيانات والإصلاحات

وحدة

Inline fictions/builders (factory methods).
اختبارات قائمة على الجدول لقيم الحدود.
النهج القائم على الملكية للثوابت (مثلاً) «مجموع الديون = مجموع الاعتمادات»).

التكامل

البيئة المحكم: Testcontainers/Docker Compose رفع «postgres + redis + kafka + wiremock».
البذور الأولية في قاعدة البيانات/المخبأ والتنظيف بعد ذلك (المعاملة/التراجع، القطع).
الساعات/المؤقتات مزيفة (يتم التحكم فيها)، وإلا فإن الفلات.

6) الأدوات والأنماط

• Stub هو إجابة ثابتة (رخيصة).
• Mock - تحقق من التفاعلات/عدد المكالمات.
• Fake هو تنفيذ مبسط (على سبيل المثال، In-Memory Repo).
• اختبار العقد (CDC): Pact/Swagger-based - أصلح توقعات العملاء وتحقق من المزود.
• WireMock/MockServer - HTTP stubs لخدمات الطرف الثالث.
• Testcontainers هم DBs/وسطاء حيون محليًا وفي CI بدون «حديقة حيوانات».

7) أمثلة

7. 1 الوحدة: باطلة الدفع (كاذب)

python def test_idempotent_create_payment_returns_same_id():
repo = InMemoryPayments()
service = Payments(repo)

first = service. create(amount=100, key="abc")
second = service. create(amount=100, key="abc")

assert first. id == second. id assert repo. count() == 1

7. 2 التكامل: توقيع Webhook (HMAC) + تكرار

bash docker-compose: app + redis + wiremock (PSP)
docker compose -f docker-compose. test. yml up -d pytest -m "integration and webhook" -q

• يقدم WireMock حدثًا مع «X-Timestamp» وتوقيع.
• يتحقق التطبيق من HMAC، ويفكك بواسطة «event _ id»، ويكرر بعد 5 ثوانٍ لا يخلق ضعف.
• نتحقق من «200» وأن هناك مدخلًا واحدًا فقط.

7. 3 CDC: عقد العميل للمزود

يقوم العميل بإنشاء ميثاق (في انتظار: "POST/v1/payout' →" 201 "مع مخطط).
يدير المزود في CI التحقق من العقد في جناحه.

8) السرعة، التوازي، الرقائق

يجب تشغيل الوحدات أقل من 100 مللي ثانية لكل اختبار ؛ حزمة - ثوان.
التكامل - بالتوازي مع الحاويات/الموانئ ؛ تستخدم هجرات الشركات الناشئة.

• وقت التحكم (ساعة مزيفة)،
• التوقعات «من خلال حدث صريح»، وليس «النوم»،
• العتبات المستقرة (retrai مع اختبار النبض بشكل حاسم).

9) مقاييس الجودة

التغطية (الخطوط/الفروع): مفيد لمراقبة الاتجاه، ولكن ليس الهدف.
اختبار الطفرة (PIT/Mutmut): يوضح ما إذا كانت الاختبارات «تقتل» التغييرات الخاطئة - القوة الحقيقية للقتلة.
مدة الاختبار والمعدل غير المستقر: تنبيهات عند النمو.
احتواء العيوب: نسبة الحشرات التي تم اعتراضها قبل الإنتاج.

10) تضمين CI/CD

الوظائف: وحدة التكامل → → e2e (التشجيع حسب الخدمة).
مخبأ التبعية، مصفوفات متوازية حسب قاعدة البيانات/اللغة/النسخة.
التقارير: JUnit/Allure + قطع أثرية لسجل الحاوية (للقطرات).
البوابة: «الوحدة الخضراء + التكامل الحرج» - حالة الدمج ؛ e2e - في الليل.

yaml strategy:
matrix:
db: [postgres14, postgres16]
steps:
- run: docker run -d --name db -e POSTGRES_PASSWORD=pw postgres:${{ matrix. db }}
- run: pytest -m "unit" -q
- run: pytest -m "integration" -q

11) الخدمات الدقيقة والأحداث

عقود الخدمة: تم التعرف على OpenAPI/Protobuf ؛ اختبارات التوافق (إلى الخلف).

• الوحدة: رسم خرائط أحداث المجال والثوابت.
• التكامل: النشر/الاشتراك في وسيط حقيقي (كافكا)، دلالات outbox/inbox، التقليد مرة واحدة بالضبط (على الأقل - خفي).
• اختبارات خارج النظام.

12) البيانات والعزلة في التكامل

كل اختبار → مخطط/قاعدة بيانات فريدة (Testcontainers JDBC URL '؟ TC _ TMPFS =/var/lib/postrescql/data: rw ').
إصلاحات المعاملات (begin→run→rollback) تسرع التنظيف.
بالنسبة إلى Redis/cache، فإن البادئة الرئيسية هي «الاختبار: $ {RUN _ ID}:» و «FLUSHDB» في تمزق.

13) تفاصيل iGaming/Finance

النقود والحدود: اختبارات قائمة على الملكية للثوابت (الرصيد ≥ 0، إجمالي القيود).
التنظيم: التحقق من التسجيل (سجل التدقيق مكتوب)، الأحداث غير القابلة للتغيير.
المدفوعات/PSP: HMAC/mTLS اختبارات التكامل، «Retry-After»، الخصوصية، dedup «jti».

اللعب المسؤول: اختبارات قاعدة العتبة/التهدئة ؛ «vchera→segodnya» على ساعة مزيفة

14) أنتيباترن

«الوحدات» التي ترفع DB/HTTP هي بالفعل تكامل (تخلط الطبقات وتبطئ CI).
تغطية عالية بسبب البيانات الفارغة («مغطاة ولكن لم يتم التحقق منها»).
منطق Moki لخدمات الطرف الثالث حيث تكون هناك حاجة إلى عقد (ينتهي عند التحديث).
اختبارات «النوم (5)» بدلاً من توقعات الحدث/الحالة.
قاعدة بيانات الاختبار الشائعة للاختبارات المتوازية → العرق والقشور.

15) قائمة التحقق من الاستعداد

• تم تعريف الهرم على أنه% من Unit/Integration/E2E والأسهم المستهدفة حسب وقت التشغيل.
• الوحدات معزولة وسريعة وتغطي القيم الحدودية والثوابت.
• يستخدم التكامل بيئة محكّمة (Testcontainers/Compose)، بدون حالات مشتركة.
• تم التحقق من اختبارات العقد (OpenAPI/Pact) في CI.
• بيانات الاختبار - المدارة: البذور/التراجع/البادئات، الساعة المزيفة.
• تشغيل متوازي، تقارير JUnit/Allure، قطع أثرية لسجل الحاويات.
• المقاييس: المدة، المعدل غير المستقر، درجة الطفرات ؛ تنبيهات إلى التدهور.
• سيناريوهات الدفع/الخطاف الشبكي: HMAC/mTLS، retrai، idempotency، deadup.
• وثائق الاستراتيجية ونماذج اختبار العينات.

16) TL ؛ د

الوحدة - الحد الأقصى للمنطق والحد الأدنى للبيئة ؛ التكامل - الحد الأدنى من الموك، أقصى قدر من الواقعية. امسك الهرم: الوحدات السريعة تلتقط 80٪ من العيوب، والتكامل يؤكد الحزم والعقود. استخدم الحاويات المحكّمة واختبارات العقد والساعة المزيفة والتوازي. قياس ليس فقط التغطية، ولكن أيضًا درجة الطفرة والمعدل المتقلب. تحقق بشكل خاص من مسارات الدفع/خطاف الويب: التوقيعات وإعادة التصوير والغباء.