واحد در مقابل تست های یکپارچه سازی
1) چرا تفاوت بین انواع آزمون
دانه بندی مناسب تست ها باعث می شود توسعه قابل پیش بینی باشد: واحد نقص منطق را به سرعت و ارزان می گیرد ؛ ادغام مجموعه ای از ماژول ها، حمل و نقل واقعی و «چسب» را بررسی می کند. "با هم، آنها رگرسیون را کاهش می دهند و انتشار را تسریع می کنند.
2) تعریف و مرزها
تست واحد
تست یک واحد کوچک از رفتار (تابع، کلاس، مورد استفاده) در انزوا.
وابستگی های خارجی جایگزین می شوند (ساختگی/خرد/جعلی).
سریع (ms-tens of ms)، قطعی.
آزمون ادغام
تعامل چندین جزء واقعی را بررسی می کند: پایگاه داده، کارگزار (Kafka/RabbitMQ)، HTTP/gRPC، سیستم فایل، حافظه پنهان.
حداقل موک، پروتکل هاي واقعي
کندتر (صدها میلی ثانیه)، گران تر در پشتیبانی.
3) هرم تست (نه شاخ یخ)
بنیاد: واحد (70-80٪ در تعداد) - ارزان، سریع.
لایه میانی: ادغام/کامپوننت (15-25٪) - مسیرهای بحرانی و قراردادها.
بالا: E2E/UX/Exploratory (5-10٪) - حداقل به اندازه کافی.
در دو طرف: تجزیه و تحلیل استاتیک/Lint/Type check و تست جهش به عنوان تقویت کننده های کیفیت.
4) چه چیزی به واحد و چه چیزی برای ادغام
5) داده ها و رفع
واحد ها
داستان های درون خطی/سازندگان (روش های کارخانه).
تست های جدول محور برای مقادیر مرزی.
رویکرد مبتنی بر اموال برای invariants (به عنوان مثال،. «مجموع بدهی = مجموع اعتبارات»).
ادغام
محیط Hermetic: Testcontainers/Docker Compose 'postgres + redis + kafka + wiremock' را افزایش می دهد.
بذر اولیه در پایگاه داده/کش و پاکسازی پس از (معامله/بازگشت، کوتاه کردن).
ساعت/تایمر جعلی (کنترل شده)، در غیر این صورت flacks.
6) ابزار و الگوهای
Mocks/Stubs/Fakes/Spies:- Stub یک پاسخ ثابت (ارزان) است.
- Mock - تعاملات/تعداد تماس ها را بررسی کنید.
- جعلی یک پیاده سازی ساده است (به عنوان مثال، In-Memory Repo).
- تست قرارداد (CDC): مبتنی بر Pact/Swagger - انتظارات مشتری را برطرف کرده و ارائه دهنده را بررسی کنید.
- WireMock/MockServer - پایه های HTTP برای خدمات شخص ثالث.
- Testcontainers DBs/کارگزاران زندگی می کنند به صورت محلی و در CI بدون «باغ وحش».
7) مثال ها
7. 1 واحد: Idempotence پرداخت (شبه کد)
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 ادغام: امضای وب هوک (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» deduplicates می کند، بعد از 5 ثانیه تکرار می کند double ایجاد نمی کند.
- ما «200» را بررسی می کنیم و فقط یک ورودی وجود دارد.
7. 3 CDC: قرارداد مشتری به ارائه دهنده
مشتری یک Pact تولید می کند (انتظار: «POST/v1/payout» → «201» با یک نمودار).
ارائه دهنده در CI، تأیید قرارداد را در جایگاه خود اجرا می کند.
8) سرعت، موازی، پوسته ها
واحد باید <100 ms در هر آزمون اجرا شود ؛ بسته - ثانیه.
ادغام - موازی با ظروف/پورت ؛ از مهاجرت های استارت آپ استفاده کنید
پادزهر کثیف:- زمان کنترل شده (ساعت جعلی)
- انتظارات «توسط رویداد صریح»، نه «خواب»،
- آستانه پایدار (retrai با آزمون jitter تعیین کننده).
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 نسخه می شوند ؛ تست های سازگاری (عقب).
رویداد محور:- واحد: نقشه برداری رویداد دامنه و ناوردا.
- ادغام: انتشار/اشتراک در یک کارگزار واقعی (کافکا)، خروجی/صندوق معانی، دقیقا یک بار تقلید (حداقل - idempotent).
- تست های خارج از دستور
12) داده ها و انزوا در ادغام
هر آزمون → طرح منحصر به فرد/پایگاه داده (Testcontainers JDBC URL '? TC _ TMPFS =/var/lib/postgresql/data: rw ').
رفع معاملات (شروع → اجرا → برگشت) سرعت تمیز کردن.
برای Redis/cache، پیشوند کلید "test: $ {RUN _ ID}:" و "FLUSHDB 'in teardown.
13) ویژگی های iGaming/امور مالی
پول و محدودیت ها: آزمون های مبتنی بر ویژگی برای ناوردایی (تعادل ≥ 0، محدودیت های کل).
نظارتی: ورود به سیستم چک (ورود به سیستم حسابرسی نوشته شده است)، حوادث غیر قابل تغییر است.
پرداخت/PSP: تست یکپارچه سازی HMAC/mTLS, 'Retry-After', idempotency, dedup 'jti'.
بازی مسئول: آزمون آستانه/خنک کننده قانون ؛ «vchera → segodnya» در ساعت جعلی.
14) ضد گلوله
«واحدهای» که DB/HTTP را افزایش می دهند، در حال حاضر یکپارچه سازی هستند (لایه های گیج کننده و کم کردن سرعت CI).
پوشش بالا به دلیل اظهارات خالی («پوشش داده شده، اما بررسی نشده»).
منطق Moki از خدمات شخص ثالث که در آن یک قرارداد مورد نیاز است (می شکند زمانی که به روز).
تست با «خواب (5)» به جای انتظارات رویداد/وضعیت.
پایگاه داده آزمون مشترک برای آزمون های موازی → نژاد و پوسته پوسته شدن.
15) تولید لیست آمادگی
- Pyramid به عنوان درصد Unit/Integration/E2E و سهام هدف توسط زمان اجرا تعریف شده است.
- واحدها جدا شده، سریع، مقادیر مرزی و ناوردا را پوشش می دهند.
- ادغام با استفاده از یک محیط hermetic (Testcontainers/Compose)، بدون حالت های مشترک.
- تست قرارداد (OpenAPI/پیمان) در CI تایید شده است.
- داده های تست - مدیریت: دانه/rollback/prefixes، ساعت جعلی.
- اجرای موازی، گزارش JUnit/Allure، مصنوعات ورود به سیستم کانتینر.
- معیارها: مدت زمان، میزان پوسته پوسته شدن، نمره جهش ؛ هشدارهایی برای کاهش وزن
- سناریوهای پرداخت/وب هوک: HMAC/mTLS، retrai، idempotency، deadup.
- مستندات استراتژی و الگوهای آزمون نمونه.
16) TL ؛ دکتر متخصص
واحد - حداکثر منطق، حداقل محیط ؛ ادغام - حداقل MOKS، حداکثر واقع گرایی. نگه داشتن هرم: واحدهای سریع گرفتن 80٪ از نقص، ادغام بسته نرم افزاری و قرارداد را تایید می کند. استفاده از ظروف hermetic، تست قرارداد، ساعت جعلی و موازی. اندازه گیری نه تنها پوشش، بلکه نمره جهش و نرخ پوسته پوسته شدن. به خصوص مسیرهای پرداخت/webhook را بررسی کنید: امضا، بازپرداخت و idempotency.