Unit vs Integration ტესტები

1) რატომ უნდა განვასხვავოთ ტესტის ტიპები?

ტესტების სწორი გრანულაცია პროგნოზირებს: Unit იჭერს ლოგიკის დეფექტებს სწრაფად და იაფად; Integration ამოწმებს მოდულის, რეალური ტრანსპორტის და „წებოს“ ლიგატებს. ერთად, ისინი ამცირებენ რეგრესს და აჩქარებენ გამოშვებებს.

2) განმარტებები და საზღვრები

ერთიანი ტესტი

ამოწმებს ქცევის მცირე ერთეულს (ფუნქცია, კლასი, ყუთი) იზოლირებულად.
გარე დამოკიდებულება შეიცვალა (mock/stub/fake).
სწრაფი (ms-ათობით ms), დეტერმინისტული.

ინტეგრაციის ტესტი

ამოწმებს რამდენიმე რეალურ კომპონენტს: BD, ბროკერი (Kafka/RabbitMQ), HTTP/gRPC, ფაილური სისტემა, ქეში.
მინიმალური შოკი, რეალური ოქმები.
უფრო ნელა (ასობით ms წამი), უფრო ძვირია მხარდაჭერა.

💡 წესი: როგორც კი „გადავდივართ პროცესს/სოკეტს/BD“ - ჩვენ უკვე ინტეგრაციის წყლებში ვართ.

3) ტესტირების პირამიდა (და არა ყინულის რქა)

ბაზა: კავშირი (70-80%) - იაფი, სწრაფად.
საშუალო ფენა: Integration/Component (15-25%) - კრიტიკული გზები და კონტრაქტები.
ზედა: E2E/UX/Exploratory (5-10%) - მინიმალური საკმარისი.
გვერდებზე: Static Analysis/Lint/Type check და Mutation testing, როგორც ხარისხის გამაძლიერებლები.

4) რა უნდა მისცეს Unit- ს და რა - Integration

ამოცანა	ტიპი	რატომ
სუფთა ბიზნეს ლოგიკა (ვალიდაცია, საკომისიოს გაანგარიშება, კლავიშების იდემპოტენტურობა)	Unit	სწრაფად, დეტერმინალურად, ბევრი სასაზღვრო მნიშვნელობა
DTO Mappings - მოდელი, სერიალიზაცია, პარსინგი	Unit	ბევრი შემთხვევა, მარტივად იზოლირება
საცავი/ORM მოთხოვნები	Integration (с test DB)	ORM და SQL ნიუანსების „ქცევა“ მხოლოდ ცოცხალ BD- ზე ჩანს
HTTP ხელშეკრულება (სტატუსები, სათაურები, სქემები)	Integration / Contract	ჩვენ გვჭირდება ცოცხალი დასტის HTTP + JSON Schema/OpenAPI
Saga/Outbox, retrai, ვადა	Integration / Component	ტაიმინგი, გარიგება, ბროკერი
Rate limit в gateway	Integration	Redis/state/Taimauts
გადახდის ვებ ჰუკები (HMAC, განმეორება)	Integration / CDC	ხელმოწერები, საათი, ქსელის მახასიათებლები

5) მონაცემები და ფიქსაცია

Unit

Inline fistures/bilders (factory methods).
ტაბლეტის ტესტები სასაზღვრო მნიშვნელობებისთვის.
Property-based მიდგომა ინვარიანტებისთვის (მაგალითად, „დებეტების ჯამი = სესხების ჯამი“).

Integration

ჰერმეტული გარემო: Testcontainers/Docker Compose ამაღლებს 'postgres + redis + kafka + wiremock'.
საწყისი თესლი BD/ქეში და გაწმენდის შემდეგ (გარიგება/rollback, truncate).
საათი/ტაიმერები - ყალბი (კონტროლირებადი), წინააღმდეგ შემთხვევაში ფლაკები.

6) ინსტრუმენტები და ნიმუშები

Mocks/Stubs/Fakes/Spies:

Stub არის ფიქსირებული პასუხი (იაფი).
მოკი - ურთიერთქმედების/ზარების რაოდენობის გადამოწმება.
ყალბი გამარტივებული განხორციელებაა (მაგალითად, In-Memory Repo).
Contract testing (CDC): Pact/Swagger-based - ჩვენ აღვნიშნავთ კლიენტის მოლოდინს და ვამოწმებთ პროვაიდერს.
WireMock/MockServer - მესამე მხარის სერვისების HTTP დანამატები.
Testcontainers - ცოცხალი DD/ბროკერები ადგილობრივად და CI- ში „ზოოპარკის“ გარეშე.

7) მაგალითები

7. 1 ერთეული: გადახდის იდემპოტენტურობა (pseudocode)

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' - ს, რეპლიკა 5 წამის შემდეგ არ ქმნის დუბლს.
ჩვენ ვამოწმებთ '200' და რომ მხოლოდ ჩანაწერია.

7. 3 CDC: კლიენტის კონტრაქტი პროვაიდერზე

კლიენტი ქმნის Pact- ს (მოლოდინი: 'POST/v1/payout' - ს სქემით).
პროვაიდერი CI- ში აყენებს ხელშეკრულების გადამოწმებას მის სკამზე.

8) სიჩქარე, პარალელი, ფლეიკი

Unit უნდა მუშაობდეს <100 ms ტესტისთვის; პაკეტი - წამები.
Integration - პარალელი კონტეინერებზე/პორტებზე; გამოიყენეთ მიგრაცია.

Flaky ანტიდოტი:

კონტროლირებადი დრო (ყალბი კლოკი),
მოლოდინები „აშკარა მოვლენის შესახებ“ და არა „ძილი“,
სტაბილური ბარიერები (გადატვირთეთ ჯიტერი დეტერმინიულად).

9) ხარისხის მეტრიკა

Coverage (ხაზები/ფილიალები): სასარგებლოა ტენდენციის დასაკვირვებლად, მაგრამ არა მიზანი.
Mutation testing (PIT/Mutmut): აჩვენებს, კლავს თუ არა ტესტები ცრუ ცვლილებებს - ასურენის რეალური ძალა.
Test duration და flaky rate: ალერტები ზრდის დროს.
Exect containment: backs- ის წილი წარმოებამდე.

10) ინტეგრაცია CI/CD- ში

ჯობი: unit - integration - e2e (სერვისების გულშემატკივარი).
დამოკიდებულების ქეში, პარალელური მატრიცები მონაცემთა ბაზის/ენების/ვერსიების მიხედვით.
მოხსენებები: JUnit/Allure + კონტეინერების ლოგოების ნიმუშები (დაცემის დროს).
კარიბჭე: „მწვანე ერთეული + კრიტიკული ინტეგრაცია“ - მერის პირობა; e2e - nightly- ზე.

მატრიცის მაგალითი (GitHub Actions, ფრაგმენტი):

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 ვერსია; თავსებადობის ტესტები (backward).

Event-driven:

კავშირი: დომენის მოვლენების მაპინგი და ინვარიანტები.
Integration: პუბლიკაცია/გამოწერა რეალურ ბროკერში (Kafka), outbox/inbox სემანტიკა, exactly-once იმიტაცია (ყოველ შემთხვევაში idempotent).
Retrai/დუბლიკატების/გადახედვის ტესტები (out-of-order).

12) მონაცემები და იზოლაცია ინტეგრაციაში

თითოეული ტესტი არის უნიკალური სქემა/BD (Testcontainers JDBC URL '? TC _ TMPFS =/var/lib/postgresql/data: rw').
გარიგების ფიქსაცია (begin-run-rollback) აჩქარებს გაწმენდას.
Redis/kesh- ისთვის - საკვანძო პრეფიქსი 'test: $ {RUN _ ID}:' და 'FLUSHDB' teardown- ში.

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

ფული და ლიმიტები: ინვარიანტის ტესტები (ბალანსი - 0, მთლიანი შეზღუდვები).
მარეგულირებელი: ჟურნალის შემოწმება (დაიწერა აუდიტი), უცვლელი მოვლენები.
გადახდები/PSP: ინტეგრაციის ტესტები HMAC/mTLS, 'Retry-After', idempotence, dedup 'jti'.
საპასუხისმგებლო თამაში: ბარიერების/ყუთების წესების ტესტები; „გუშინ დღეს“ ყალბი clock.

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

„Unit“, რომელიც ზრდის BD/NTTR, უკვე ინტეგრაციაა (დაბნეული ფენები და ანელებს CI).
მაღალი ანაზღაურება ცარიელი განცხადებების გამო („დაფარული, მაგრამ არ შემოწმებულა“).
მესამე მხარის სერვისების ლოგიკის ხიდები, სადაც საჭიროა კონტრაქტი (იშლება განახლების დროს).
ტესტები 'ძილის (5)' ნაცვლად ღონისძიების/პირობების მოლოდინის ნაცვლად.
პარალელური ტესტებისთვის მთლიანი ტესტის DD არის რბოლა და ფლეიკა.

15) მზადყოფნის სიის სია

პირამიდა განისაზღვრება: Unit/Integration/E2E წილის% და Progon დროის მიზნები.
ერთეული არის იზოლირებული, სწრაფი, მოიცავს სასაზღვრო მნიშვნელობებს და ინვარიანტებს.
Integration გამოიყენება ჰერმეტული გარემო (Testcontainers/Commose), ზოგადი სტეიტების გარეშე.
ხელშეკრულების ტესტები (OpenAPI/Pact) გადამოწმდება CI- ში.
ეს ტესტები - კონტროლირებადი: seed/rollback/პრეფიქსი, ყალბი clock.
პარალელური პროგონი, JUnit/Allure მოხსენებები, კონტეინერების ლოგოების არტეფაქტები.
მეტრიკა: duration, flaky rate, mutation score; ალერტები დეგრადაციისთვის.
გადახდის/ვებჰუკის სცენარები: HMAC/mTLS, retrai, idempotence, დედაპლატი.
სტრატეგიის დოკუმენტაცია და ტესტის შაბლონების მაგალითები.

16) TL; DR

Unit - მაქსიმალური ლოგიკა, მინიმალური გარემო; Integration - მინიმალური ბუჩქები, მაქსიმალური რეალიზმი. შეინარჩუნეთ პირამიდა: სწრაფი კავშირი იჭერს დეფექტების 80% -ს, ინტეგრაცია ადასტურებს ლიგატებსა და კონტრაქტებს. გამოიყენეთ ჰერმეტული კონტეინერები, საკონტრაქტო ტესტები, ყალბი clock და პარალელურობა. გაზომეთ არა მხოლოდ შეგროვება, არამედ მუტაციის სკორეტი და მფრინავი რბოლა. განსაკუთრებით შეამოწმეთ გადახდის/ვებჰუკის ბილიკები: ხელმოწერები, რეკრუტირება და იდემპოტენტობა.

Unit vs Integration ტესტები

ინტეგრაციის ტესტი

Integration

დაგვიკავშირდით

სწრაფი კავშირი

ვიდეო მალე განახლდება

ჩვენ ახლა ძალიან დაკავებული ვართ პროექტებით