مسخره کردن و خرد کردن برای ادغام

1) چرا ما نیاز به midges و شاخه

• جداسازی منطق سرویس از یک محیط ناپایدار
• تعیین پاسخ ها و خطاها
• بازتولید موارد مرزی نادر (زمان بندی، 429/5xx، ناسازگاری) ؛
• تست ها را به صورت محلی و در CI به سرعت و قابل پیش بینی انجام دهید.

2) شرایط و طبقه بندی

Stub یک خرد ساده با پاسخ ثابت، بدون بررسی تعامل است.
Mock - شی ای که منتظر تماس است و آنها را تأیید می کند (سفارش/شماره/استدلال).
جعلی یک پیاده سازی ساده (به عنوان مثال، یک مخزن در حافظه) با رفتار واقعی است.
Spy یک بسته بندی است که تماس های واقعی را ضبط می کند.
مجازی سازی سرویس یک سرویس خارجی «مجازی» با اسکریپت ها، وضعیت و ویژگی های شبکه است.
ضبط/پخش - ضبط ترافیک واقعی و پخش پس از آن (با فیلتر/نسخه).

3) الگوهای معماری برای تست پذیری

پورت ها و آداپتورها (شش ضلعی): ادغام را فراتر از رابط ها انجام دهید - جایگزینی آن با جعلی/ساختگی آسان است.
لایه ضد فساد (ACL): یک ماژول یک مدل خارجی را به یک مدل دامنه ترجمه می کند - نقاط moka کمتر.
مشتریان آگاه از قرارداد: تولید OpenAPI/Protobuf → تناقضات کتابچه راهنمای کاربر کمتر است.
پرچم های ویژگی و حالت های sandbox: کلید های امن/نقاط پایانی برای پایدار ارائه دهنده.

4) HTTP: ابزار و نمونه

4. 1 WireMock (مستقل/جاوا DSL)

json
{
"request": { "method": "POST", "urlPath": "/v1/payouts", "headers": { "Idempotency-Key": { "matches": ".+" } } },
"response": {
"status": 201,
"headers": { "Content-Type": "application/json" },
"jsonBody": { "id": "po_123", "status": "queued" },
"fixedDelayMilliseconds": 80
}
}

java stubFor(post(urlEqualTo("/v1/payouts"))
.withHeader("Idempotency-Key", matching(".+"))
.withRequestBody(matchingJsonPath("$.amount", equalTo("100. 00")))
.willReturn(aResponse(). withStatus(201). withHeader("Content-Type","application/json")
.withBody("{\"id\":\"po_123\",\"status\":\"queued\"}")));

4. 2 MockServer (دینامیک/تایید)

json
{
"httpRequest": { "method": "GET", "path": "/v1/wallets/w123" },
"httpResponse": { "statusCode": 200, "headers":[{"name":"Content-Type","values":["application/json"]}],
"body": { "id":"w123","currency":"EUR","balance":0 } }
}

4. 3 هاور فلای (میان افزار، ضبط/پخش)

ترافیک را در برابر sandbox ارائه دهنده ضبط کنید، PII را پاک کنید، آن را به عنوان ثابت ثابت کنید.
در حالت شبیه سازی، تغییرات را اضافه کنید: 200/4xx/5xx، تاخیر و پنجره های «پوسته پوسته».

4. 4 گره (ناک )/پایتون (پاسخ )/برو (htttest)

js nock('https://psp. example. com')
.post('/v1/payouts'). reply(201, { id:'po_123', status:'queued' })
.post('/v1/payouts'). reply (409, {code: 'duplicate'}) ;//second call - conflict

go srv:= httptest. NewServer(http. HandlerFunc(func(w http. ResponseWriter, r http. Request){
if r. Header. Get("Idempotency-Key") == "" { w. WriteHeader(400); return }
w. Header(). Set("Content-Type","application/json")
w. WriteHeader(201); w. Write([]byte(`{"id":"po_123","status":"queued"}`))
}))
defer srv. Close()

5) gRPC/Protobuf

5. 1 نسل چاقو

با استفاده از «.proto» یک سرور ایجاد کنید، متدها را با پاسخهای کنترل شده اجرا کنید.
بررسی فراداده) سرآیند (، وضعیتها) "کدها. آرگومان نامعتبر '،' کدها. مهلت بیش از حد).

go type FakePayouts struct{ pb. UnimplementedPayoutsServer }
func (f FakePayouts) Create(ctx context. Context, in pb. PayoutReq)(pb. PayoutRes,error){
if in. Amount <= 0 { return nil, status. Error(codes. InvalidArgument,"amount>0") }
return &pb. PayoutRes{Id:"po_123", Status:"QUEUED"}, nil
}

5. 2 grpcurl برای منفی

grpcurl -plaintext -d '{"amount":0}' localhost:50051 payouts. Payouts/Create

6) پست ها و جریان ها: کافکا/RabbitMQ

6. 1 موکی آگاه از طرح

از Schema Registry استفاده کنید و Avro/JSON-Schema/Protobuf را در تستها تأیید کنید.
آزمون تولیدکننده: پیام مربوط به طرحواره است ؛ تست مصرف کننده: نسخه های قدیمی و جدید را می پذیرد.

6. 2 Testcontainers (کافکا + مثال رجیستری)

java
KafkaContainer kafka = new KafkaContainer(DockerImageName. parse("confluentinc/cp-kafka:7. 6. 1"));
kafka. start();
//We publish the event and wait for consumption with deduplication by key

6. 3 منفی

تکراری، تنظیم مجدد سفارش، تاخیر تحویل، پیام های «سمی» (حرف مرده).
پیام های بزرگ (نزدیک به حد)، نسخه های طرح ناشناخته.

7) شاخه های قرارداد آگاه

7. 1 پیمان (CDC mocks)

مصرف کننده تولید انتظارات → فایل پیمان → ارائه دهنده تایید در غرفه.
سرور خرد Pact انتظارات برای تست های یکپارچه سازی مشتری را بازی می کند.

7. 2 OpenAPI/Protobuf → تولید پایدار

ابزارهایی که سرور مجازی را از مشخصات بالا می برند (از جمله Prism، openapi-mock، grpc-mock).
مثالها/کدهای منفی را در مشخصات ذکر کنید: این نیز یک قرارداد است.

8) شبکه و هرج و مرج: شبیه سازی شکست

تاخیر و لرزش: ثابت/توزیع شده ؛ check deadline and per-try timeout را بررسی کنید.
وقفه/استراحت: اتصالات نیمه باز، RST، تنظیم مجدد جریان H2، 503/Retry-After.
از دست دادن بسته/تکراری: برای gRPC/جریان.
ابزار: Toxiproxy، MockServer (تزریق خطا)، xk6-disruptor، netem در CI.

toxiproxy-cli toxic add psp --type latency --latency 300 --jitter 100

9) داده ها، اسرار و جبرگرایی

اصلاح و مصنوعی: بدون PII در رفع ؛ پول - قالب بندی اعشاری/سخت.
تثبیت زمان: ساعت جعلی ؛ «دیروز/امروز» - کنترل.
Idempotency: همان «Idempotency-Key» → همان پاسخ.
ژنراتور: کارخانه ها/سازندگان داده ها با مقادیر شفاف (به عنوان مثال، 'test _ user _ 001').
رفع نسخه (برچسب ها)، پاسخ های «حذف شده» را بدون واسطه ذخیره نکنید.

10) CI/CD و محیط

ماتریس: واحد (در فرآیند جعلی) → جزء (مجازی سازی محلی) → ادغام (حداقل moks، Testcontainers).
مصنوعات: فایل های پیمان، عکس های فوری OpenAPI، سیاهههای مربوط به سرور ioc، PCAP برای قطره.
موازی: پورت های منحصر به فرد/پیشوندهای کلیدی ؛ عایق بندی ظروف.
دروازه: قرارداد سبز (CDC تایید)، مشخصات معتبر (lint)، منفی گذشت.

11) ضد گلوله

Moki «کپی» نقص در خدمات واقعی → اعتماد به نفس کاذب. تحت درمان با قراردادها و ثبت/تأیید دوره ای.
«macromocks» از کل جهان در هر آزمون → شکنندگی، جریان اصلی گران است. پورت های نازک و ACL ها را ایجاد کنید.
Moki در E2E که در آن ادغام واقعی مورد نیاز است (به خصوص پرداخت/webhooks با HMAC/mTLS).
Flakes با توجه به زمان/تصادفی/مسابقه شبکه → استفاده از ساعت جعلی، صندلی قطعی.
اسرار در رفع/مخازن. اسرار - فقط از طریق ذخیره سازی مخفی CI.

12) مشخصات iGaming/امور مالی

پرداخت/برداشت: Mokes باید از «Idempotency-Key»، «Retry-After»، HMAC/mTLS، کدهای تحریم و پاسخ های «طولانی» پشتیبانی کند.
منطق پاداش/ضد تقلب: سناریوهای سرعت/429، ATO/چالش، راه حل های ریسک «اجازه/انکار/چالش» با TTL.
KYC/AML: پاسخ های sandbox با سطوح KYC، منفی ها (عدم تطابق، اسناد نامعتبر)، وب سایت ها با anti-replay (پنجره X-Timestamp).
حوزه های قضایی/مستاجران: عنوان های مورد نیاز «X-Tenant/X-Region»، پروفایل های مختلف پاسخ.

13) دستور العمل های کوچک (ورق تقلب)

تکرار پرداخت: WireMock «سناریوها» - اول '201'، دوم '409 تکراری'.
PSP آهسته: MockServer 'responseDelay' + چک کردن هر بار امتحان در مشتری.
Webhooks: سرور HTTP محلی + تأیید امضای HMAC ؛ تکرار پس از 5 ثانیه دوبل ایجاد نمی کند.
تکراری کافکا: ارسال همان پیام دو بار ؛ گرداننده باید بیکار باشد.
وضعیت gRPC: ماتریس «کدهای» آزمون (InvalidArgument، DeadlineExceeded، ResourceExhausted).

14) تولید لیست آمادگی

• پورت ها/آداپتورها برجسته می شوند ؛ یکپارچگی در پشت رابط ها پنهان شده است.
• برای HTTP/gRPC - stabs قرارداد آگاه (Pact/OpenAPI/Proto) با منفی وجود دارد.
• برای کارگزاران - Testcontainers + رجیستری ؛ تست های پیام تکراری/سفارش/بزرگ.
• هرج و مرج: تاخیر، وقفه، تنظیم مجدد، 429/503 با 'Retry-After' ؛ شبکه شبیه سازی شده است (Toxiproxy/netem).
• لامپ بدون PII ؛ ساعت تقلبی idemotency تعیین شده است.
• ماتریس CI: واحد → جزء → ادغام ؛ مصنوعات log/contract حفظ می شوند.
• sandboxes ارائه دهنده: کلید از هم جدا، endpoints پیکربندی شده اند، یک runbook وجود دارد.
• ضبط/پخش در برنامه به روز می شود، ردیابی ها ویرایش می شوند.
• معیارهای پوسته پوسته و مدت زمان تست تحت کنترل ؛ هشدارهایی برای رشد

15) TL ؛ دکتر متخصص

یکپارچه سازی را از طریق پورت های نازک جدا کنید و از ابزار مناسب برای این کار استفاده کنید: برای موارد ساده، برای تأیید تعاملات، تقلبی برای رفتار واقع بینانه، مجازی سازی خدمات و هرج و مرج برای شبکه و خطاهای نادر استفاده کنید. Moki را قرارداد آگاهانه (Pact/OpenAPI/Proto)، نگه داشتن رفع قطعی و PII رایگان، شبیه سازی تاخیر/زمان بندی/429/5xx. در CI، ساخت یک هرم: واحد → جزء → ادغام ؛ بلوک آزادی با قراردادهای قرمز برای مسیرهای پرداخت/CCM، HMAC/mTLS، idempotence و سناریوهای منفی را در نظر بگیرید.