Mocking და stubs ინტეგრაციისთვის

1) რატომ გვჭირდება ხიდები და დანამატები

• სამსახურის ლოგიკის იზოლირება არასტაბილური გარემოდან;
• პასუხებისა და შეცდომების დეტერმინაცია;
• იშვიათი სასაზღვრო შემთხვევების რეპროდუცირება (ტაიმაუტები, 429/5xx, არაკონსტიტუციურობა);
• დაიწყეთ ტესტები ადგილობრივად და CI- ში სწრაფად და პროგნოზირებად.

2) ტერმინები და ტაქსონომია

Stub არის მარტივი დანამატი ფიქსირებული პასუხით, ურთიერთქმედების შემოწმების გარეშე.
მოკი არის ობიექტი, რომელიც ელოდება გამოწვევებს და ასახავს მათ (ბრძანება/რაოდენობა/არგუმენტები).
ყალბი - გამარტივებული განხორციელება (მაგალითად, In-Memory საცავი) რეალური ქცევით.
Spy არის შეფუთვა, რომელიც ჩაწერს ფაქტობრივ გამოწვევებს.
Virtualization Service - „ვირტუალური“ გარე სერვისი სცენარებით, მდგომარეობით და ქსელის მახასიათებლებით.
Record/Replay არის რეალური ტრეფიკის ჩანაწერი და შემდგომი რეპროდუქცია (ფილტრებით/გამოცემით).

3) არქიტექტურული ნიმუშები ტესტირებისთვის

Ports & Adapters (Hexagonal): ინტერფეისების ინტეგრაცია - ადვილია შეცვალოთ ყალბი/ბლოკით.
ანტიკორუფციული ფენა (ACL): ერთი მოდული გარდაქმნის გარე მოდელს აფეთქების ღუმელში - მუხის წერტილებზე ნაკლები.
Contract-aware მომხმარებლები: OpenAPI/Protobuf- ის წარმოება ნაკლები ხელით შეუსაბამობაა.
Feature დროშები და sandbox რეჟიმები: უსაფრთხო გასაღებები/ენდოინები პროვაიდერის სტაბილურობისთვის.

4) HTTP: ინსტრუმენტები და მაგალითები

4. 1 WireMock (standalone/Java 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 Hoverfly (middleware, record/replay)

ჩაწერეთ ტრეფიკი პროვაიდერის „ქვიშის ყუთის“ წინააღმდეგ, გაასუფთავეთ PII, დააფიქსირეთ როგორც fixture.
Simulate რეჟიმში დაამატეთ ვარიაციები: 200/4xx/5xx, შეფერხებები და „მცურავი“ ფანჯრები.

4. 4 Node (Nock) / Python (responses) / Go (`httptest`)

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' მიხედვით, გააცნობიერეთ მეთოდები კონტროლირებადი პასუხებით.
შეამოწმეთ მეტამონაცემები, სტატუსები ('codes. InvalidArgument`, `codes. DeadlineExceeded`).

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) შეტყობინებები და ნაკადები: Kafka/RabbitMQ

6. 1 Schema-aware mocks

გამოიყენეთ Schema Registry და გამოიყენეთ Avro/JSON-Schema/Protobuf ტესტებში.
პროდუქტის ტესტი: შეტყობინება შეესაბამება სქემას; Consumer ტესტი: იღებს ძველ და ახალ ვერსიას.

6. 2 Testcontainers (მაგალითი Kafka + Registry)

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 უარყოფითი მხარეები

დუბლიკატები, წესრიგის შეცვლა, მიწოდების შეფერხება, „შხამიანი“ შეტყობინებები (მკვდარი მესიჯი).
დიდი შეტყობინებები (near-limit), სქემების არაცნობიერი ვერსიები.

7) Contract-aware დანამატები

7. 1 Pact (CDC mocks)

Consumer ქმნის მოლოდინს - pact ფაილი გადამოწმებულია სტენდზე.
Pact stub სერვერი ასახავს კლიენტის ინტეგრაციის ტესტების მოლოდინს.

7. 2 OpenAPI/Protobuf - სტაბილური წარმოება

ინსტრუმენტები, რომლებიც მაიკ სერვერს აყენებენ სპეციფიკაციიდან (მათ შორის Prism, openapi-mock, grpc-mock).
ჩართეთ უარყოფითი მაგალითები/კოდები სპეციფიკაციაში: ეს ასევე არის კონტრაქტი.

8) ქსელი და ქაოსი: უარის თქმის სიმულაცია

შეფერხებები და ჯიტერი: ფიქსირებული/განაწილებული; შეამოწმეთ ვადები და პრე-try timeout.
ტაიმაუტები/შესვენებები: half-Open კავშირი, RST, Reset Stream H2, 503/Retry-After.
პაკეტის ზარალი/დუბლიკატები: GRPC/strimes.
ინსტრუმენტები: Toxiproxy, MockServer (fault injection), xk6-disruptor, netem CI- ში.

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

9) მონაცემები, საიდუმლოებები და დეტერმინიზმი

Redact და სინთეზური: არ არის PII ფიქსატორებში; ფული - decimal/მკაცრი ფორმატირება.
დროის ფიქსაცია: ყალბი clock; „გუშინ/დღეს“ - გააკონტროლეთ.
Idempotence: იგივე „Idempotency-Key“ იგივე პასუხია.
გენერატორები: ქარხნები/ბილდერები გამჭვირვალე მნიშვნელობებით (ე. g., `test_user_001`).
ვერსიები გამოიყენეთ (ჭდეები), არ შეინახოთ „ამოღებული“ პასუხები მედიაციის გარეშე.

10) CI/CD და გარემო

მატრიცა: unit (in-process fakes) - component (ადგილობრივი ვირტუალიზაცია) - integration (მინიმალური docks, Testcontainers).
ნიმუშები: pact ფაილები, OpenAPI snapshots, mock სერვერების ლოგოები, PCAP შემოდგომაზე.
პარალელურობა: უნიკალური გასაღების პორტები/პრეფიქსი; კონტეინერების იზოლაცია.
Gate: მწვანე კონტრაქტი (CDC verify), სპეციფიკაცია არის ნამდვილი, ნეგატივები დასრულებულია.

11) ანტიპატერები

მოკი „კოპირებს“ რეალური სერვისის დეფექტებს და ცრუ ნდობას. მკურნალობენ კონტრაქტებით და პერიოდული ჩანაწერებით.
ყველა ტესტში მთელი მსოფლიოს „მაკრომოკი“ არის მყიფეობა, ძვირადღირებული მეინთენი. გააკეთეთ თხელი პორტები და ACL.
Moks in E2E, სადაც საჭიროა რეალური ინტეგრაცია (განსაკუთრებით გადახდები/ვებჰუკები HMAC/mTLS- ით).
ფლეიკები დროის/რანდომის/ქსელის რბოლების გამო, შეგიძლიათ გამოიყენოთ ყალბი ჯოხი, დეტერმინისტული ადგილები.
საიდუმლოებები ფიქსატორებში/საცავებში. საიდუმლოებები - მხოლოდ CI საიდუმლო საცავის საშუალებით.

12) iGaming/ფინანსების სპეციფიკა

გადახდები/დასკვნები: mokes უნდა დაეხმაროს 'Idempotency-Key', 'Retry-After', HMAC/mTLS, სანქციების კოდები და „გრძელი“ პასუხები.
ბონუს ლოგიკა/ანტიფროდი: სცენარები velocity/429, ATO/Challenge, რისკის გადაწყვეტა 'allow/deny/challenge' TTL- ით.
KYC/AML: sandbox პასუხები KYC- ს დონეზე, ნეგატივები (mismatch, არასწორი დოკუმენტები), ვებ - ჰუკები anti-replay ('X-Timestamp' ფანჯარა).
იურისდიქციები/ტენანტები: სავალდებულო სათაურები 'X-Tenant/X-Region ", პასუხის სხვადასხვა პროფილები.

13) მინი რეცეპტები (ყალბი ფურცელი)

გადახდის განმეორება: WireMock „Scenarios“ - პირველი '201', მეორე '409 duplicate'.
ნელი PSP: MockServer 'responseDelay' + კლინიკაში წინასწარი დროის შემოწმება.
Webhooks: ადგილობრივი HTTP სერვერი + HMAC ხელმოწერის გადამოწმება; რეპლიკა 5 წამის შემდეგ არ ქმნის დუბლს.
Kafka დუბლიკატები: გამოაქვეყნეთ იგივე შეტყობინება ორჯერ; ჰენდლერი უნდა იყოს იდემპოტენტი.
GRPC სტატუსები: matrix ტესტები 'codes' (InvalidArgument, Deadline Exceeded, ResourceExhausted).

14) მზადყოფნის ჩეკის სია

• პორტები/გადამყვანები; ინტეგრაცია იმალება ინტერფეისების მიღმა.
• HTTP/gRPC- სთვის - არსებობს კონტრაქტის სტაბილურობა (Pact/OpenAPI/Proto) ნეგატიებით.
• ბროკერებისთვის - Testcontainers + Registry; დუბლიკატების/შეკვეთის/დიდი შეტყობინებების ტესტები.
• ქაოსი: შეფერხებები, ტაიმაუტები, reset, 429/503 ერთად 'Retry-After'; ქსელი ემისირდება (Toxiproxy/netem).
• ფიქსატორები PII გარეშე; fake clock; idempotence არის აღბეჭდილი.
• მატრიქსი CI: ერთჯერადი კომპონენტის ინტეგრაცია; შენარჩუნებულია ლოგოების/კონტრაქტების არტეფაქტები.
• პროვაიდერების ქვიშაქვები: გასაღებები გამოყოფილია, ენდოინები კონფიგურირებულია, არის runbook.
• Record/Replay განახლებულია გრაფიკით, ტრასები რედაქტირებულია.
• ფლაკონის მეტრიკა და ტესტების ხანგრძლივობა კონტროლდება; ალერტები ზრდის დროს.

15) TL; DR

კონფიგურაცია მოახდინეთ თხელი პორტების საშუალებით და გამოიყენეთ სწორი ინსტრუმენტი ამოცანისთვის: stubs მარტივი შემთხვევებისთვის, mocks ურთიერთქმედებების გადამოწმებისთვის, ყალბი რეალისტური ქცევისთვის, სერვისის ვირტუალიზაციისთვის და ქაოსისთვის - ქსელური და იშვიათი შეცდომებისთვის. გახადეთ mocks კონტრაქტი შეგნებულად (Pact/OpenAPI/Proto), შეინარჩუნეთ fixtures დეტერმინირებული და PII- ის გარეშე, დააკონკრეტეთ შეფერხებები/ტაიმაუტები/429/5xx. CI- ში აშენეთ პირამიდა: ერთჯერადი კომპონენტის ინტეგრაცია; გამოშვება დაბლოკილია წითელი კონტრაქტებით. გადახდის/KUS ბილიკებისთვის გაითვალისწინეთ HMAC/mTLS, imempotence და უარყოფითი სცენარები.