CDC یا E۲E؟ راهنمای تصمیم برای تست میکروسرویس

همه Contract Testها سبزند، اما خرید واقعی به‌دلیل route اشتباه به نسخه قدیمی سرویس پرداخت می‌رود. در تیم دیگری، E2E خرید سبز است، ولی یک نسخه قدیمی اپ موبایل بعد از حذف فیلد API می‌شکند. مورد اول را CDC به‌تنهایی نمی‌بیند؛ مورد دوم را یک journey محدود E2E نمی‌بیند. سؤال درست «CDC یا E2E؟» نیست؛ سؤال این است که هر کدام دقیقاً چه ادعایی را با چه نسخه و محیطی اثبات می‌کند؟

در این راهنما، تست CDC در میکروسرویس را با E2E از منظر مرز شواهد، سازگاری نسخه‌ها، هزینه بازخورد و تصمیم انتشار مقایسه می‌کنیم. نتیجه، یک مدل عملی است: قراردادها سازگاری یال‌های گراف سرویس را می‌سنجند؛ چند E2E هدفمند، مسیرهای چندمرحله‌ای و واقعیت استقرار را.

جایگاه این مقایسه در استراتژی میکروسرویس

CDC و E2E فقط دو بخش از سبدند. Unit، Component، DB/Queue Integration، Contract، Performance، Security، Exploratory و Production Verification نیز لازم‌اند. برای نقشه کامل از Unit تا production به مقاله استراتژی تست میکروسرویس‌ها مراجعه کنید. این صفحه عمداً روی تصمیم میان شواهد Contract و شواهد مسیر deployشده تمرکز دارد.

اول واژه‌ها را دقیق کنیم

Contract Testing چیست؟

Contract Testing سازگاری interaction در یک مرز را بررسی می‌کند: request/response، message payload، metadata و قواعد matching. قرارداد ممکن است از schema ارائه‌دهنده، توافق مشترک یا نیاز مصرف‌کننده ساخته شود.

Consumer-Driven Contract یا CDC چیست؟

در CDC، نیاز واقعی Consumer قرارداد را شکل می‌دهد. Consumer با client واقعی خود interaction را اجرا می‌کند و artifact قرارداد تولید می‌شود؛ Provider همان interaction را در برابر کد خود verify می‌کند. مستندات How Pact works چرخه Consumer test، Pact file و Provider verification را توضیح می‌دهد.

هر Contract Test الزاماً CDC نیست. بررسی OpenAPI یک Provider بدون انتظارات مصرف‌کننده، Provider Contract Test است؛ مفید است، اما ادعای متفاوتی دارد.

E2E چیست؟

تست سرتاسری یک capability را از ورودی عمومی تا outcome نهایی، میان چند component یا service deployشده طی می‌کند. رابط می‌تواند UI، API، event یا CLI باشد. E2E مترادف Selenium/Browser نیست و «کل سیستم در همه حالت‌ها» را هم معنا نمی‌دهد.

مدل گراف: یال‌ها با مسیرها فرق دارند

معماری میکروسرویس را گرافی در نظر بگیرید:

• Node: سرویس یا سیستم مستقل؛
• Edge: HTTP/gRPC/message interaction میان دو node؛
• Path: زنجیره‌ای از edgeها برای یک capability کسب‌وکار؛
• Runtime: routing، certificate، policy، config، identity، data و resource واقعی.

CDC عمدتاً روی edge کار می‌کند. E2E یک path را در runtime مشخص طی می‌کند. سبزبودن همه edgeهای شناخته‌شده لزوماً composition را اثبات نمی‌کند؛ سبزبودن یک path نیز همه حالت‌ها و نسخه‌های هر edge را پوشش نمی‌دهد.

CDC دقیقاً چه چیزی را می‌تواند ثابت کند؟

با فرض اینکه تست Consumer از client واقعی استفاده کند، Provider State کنترل‌شده باشد، matching درست تعریف شود و نتیجه verification به نسخه‌ها متصل باشد، CDC شواهد زیر را می‌دهد:

• Consumer می‌تواند request مورد انتظار را بسازد و response نمونه را بخواند؛
• Provider می‌تواند برای state تعریف‌شده، response سازگار تولید کند؛
• تغییر Provider کدام expectation مصرف‌کننده شناخته‌شده را می‌شکند؛
• کدام جفت نسخه Consumer/Provider در Matrix نتیجه verification دارد؛
• تغییر قرارداد پیش از deploy و نزدیک به commit دیده می‌شود.

این شواهد برای evolution مستقل سرویس‌ها بسیار ارزشمند است. جزئیات matcher، Provider State، selectors و نمونه کد در راهنمای تست قراردادی API با Pact آمده است.

CDC چه چیزی را ثابت نمی‌کند؟

• درستی کامل منطق داخلی Provider یا Consumer؛
• نتیجه یک workflow چندسرویسی، Saga یا compensation؛
• service discovery، ingress، DNS، TLS، policy، secret و config deployشده؛
• latency، throughput، resilience، security یا accessibility؛
• سازگاری مصرف‌کننده‌ای که قرارداد منتشر نکرده یا قابل‌شناسایی نیست؛
• delivery semantics صف مانند duplicate، ordering، retry و DLQ؛
• معنای کسب‌وکاری که در قرارداد encode نشده است؛
• سازگاری نسخه‌ای که verification/result/deployment آن اشتباه ثبت شده است.

برای نمونه، اگر هر دو طرف فیلد amount: 125000 را عدد بدانند اما یکی آن را تومان و دیگری ریال تفسیر کند، schema سبز می‌ماند. نام amountRial، currency صریح، مثال معنادار و تست invariant کسب‌وکار لازم‌اند.

E2E دقیقاً چه چیزی را می‌تواند ثابت کند؟

یک E2E پاس‌شده نشان می‌دهد همان journey، با همان buildها، config، data، dependency و زمان اجرا، outcome موردانتظار را تولید کرده است. این سطح برای این ریسک‌ها مناسب است:

• ترکیب چند interaction و state transition؛
• routing، authentication و authorization میان سرویس‌ها؛
• migration و configuration محیط؛
• اتصال UI/API Gateway به سرویس‌های واقعی؛
• یک یا چند Critical User Journey؛
• Smoke یا synthetic پس از استقرار.

راهنمای Testing Strategies in a Microservice Architecture Contract و E2E را لایه‌های مکمل می‌بیند و هزینه بالای suite سرتاسری گسترده را گوشزد می‌کند.

E2E چه چیزی را ثابت نمی‌کند؟

• هر edge و هر نسخه Consumer/Provider سازگار است؛
• همه error responseها و edge caseها پوشش دارند؛
• علت failure کدام سرویس یا dependency است؛
• نتیجه فردا با config، data یا traffic دیگر تکرار می‌شود؛
• رفتار امن، سریع یا resilient است مگر همان ویژگی Oracle و workload داشته باشد؛
• مصرف‌کننده قدیمی موبایل که در journey حضور ندارد سالم می‌ماند.

E2E «اطمینان بالاتر» به‌طور مطلق نیست؛ fidelity آن برای یک path بیشتر است، ولی پوشش interaction و تشخیص failure معمولاً محدودتر است.

مقایسه CDC و E2E در یک جدول تصمیم

بُعد	CDC	E2E
ادعای اصلی	سازگاری interaction میان نسخه‌های شناخته‌شده	کارکرد یک capability در runtime مشخص
دامنه	یک Consumer–Provider edge	یک path چندجزئی
محیط	Consumer isolated + Provider محلی/CI	سرویس‌های deployشده و dependencyهای منتخب
بازخورد	معمولاً سریع و نزدیک به PR	معمولاً کندتر و دیرتر
تشخیص failure	interaction/نسخه مشخص	نیازمند trace و شواهد چند سرویس
پوشش حالت‌ها	interactionهای مصرف‌شده، با هزینه نسبتاً کم	تعداد محدود journey و state
fidelity استقرار	پایین؛ deployment را دور می‌زند	بالاتر، اگر environment واقعی باشد
وابستگی تیمی	چرخه قرارداد، Broker و ownership مشترک	مالکیت محیط و triage چندتیمی
مناسب برای	تغییر API/message میان سرویس‌های تحت‌کنترل	composition، config و Critical Journey
نامناسب برای	Public/third-party، load/security و pass-through مبهم	جدول بزرگ همه error/edge caseها

درخت تصمیم: کدام شاهد لازم است؟

1. آیا ریسک در request/response یا message میان دو تیم است؟ Contract/CDC کاندید اصلی است.
2. آیا Consumer شناخته‌شده و Provider تحت‌کنترل است؟ اگر بله، CDC ارزش بیشتری دارد؛ اگر نه، schema/conformance، adapter test و sandbox را بررسی کنید.
3. آیا ریسک فقط با ترکیب چند edge ایجاد می‌شود؟ Component orchestration یا E2E هدفمند لازم است.
4. آیا ریسک در deploy/config/network/TLS/policy است؟ E2E/Smoke/Probe deployشده لازم است؛ CDC آن را دور می‌زند.
5. آیا ریسک ordering/duplicate/retry صف است؟ Message Contract برای payload، اما Integration/E2E برای delivery semantics لازم است.
6. آیا ریسک performance یا security است؟ تست تخصصی با workload/threat مناسب اضافه کنید؛ هیچ‌کدام به‌طور پیش‌فرض کافی نیست.
7. آیا همان ادعا پایین‌تر اثبات شده است؟ در E2E فقط assertion منحصربه‌فرد path را نگه دارید.

این تصمیم با مدل هرم تست و کوچک‌ترین مرز مسئول هم‌راستاست: مرزی را انتخاب کنید که مکانیزم خرابی را حفظ می‌کند، نه صرفاً پایین‌ترین یا محبوب‌ترین ابزار را.

چه زمانی Pact و CDC انتخاب مناسبی نیست؟

راهنمای رسمی When to use Pact شرایط مناسب و نامناسب را صریح می‌کند. CDC بیشترین ارزش را دارد وقتی هر دو طرف فعال و تحت‌کنترل‌اند، Consumerها قابل‌شناسایی‌اند، Provider State قابل‌کنترل است و تیم‌ها کانال همکاری دارند.

احتیاط یا جایگزین لازم است وقتی:

• API عمومی با مصرف‌کنندگان ناشناخته دارید؛
• طرف سوم مانند PSP قرارداد Pact شما را verify نمی‌کند؛
• داده Provider را نمی‌توان مستقل و deterministic ساخت؛
• Provider فقط payload را بدون validation به downstream پاس می‌دهد؛
• هدف اصلی load، security، usability یا workflow کامل است؛
• تیم‌ها قرارداد را artifact یک‌طرفه و بدون ownership می‌بینند.

برای PSP بیرونی، ترکیب adapter test با Stub کنترل‌شده، validation قرارداد رسمی، sandbox و تعداد محدودی probe امن معمولاً بهتر از قراردادی است که Provider هیچ‌گاه verify نمی‌کند.

قرارداد خوب باید از Client واقعی ساخته شود

اگر تست Consumer دستی یک JSON نمونه به Mock بفرستد اما محصول از client دیگری استفاده کند، قرارداد درباره کد واقعی ادعایی ندارد. interaction باید همان serialization، header، auth adapter و deserialization مسیر production را طی کند.

Request دقیق، Response انعطاف‌پذیر اما ایمن

Consumer دقیقاً می‌داند چه requestی می‌فرستد، پس method، path، header و body مهم را مشخص کند. در response فقط فیلدها و قواعدی را الزام کند که واقعاً مصرف می‌شوند؛ الزام بی‌دلیل به تمام response، Provider را به جزئیات غیرمصرفی قفل می‌کند. انعطاف نباید نوع، enum، واحد یا constraint امنیتی را بی‌اثر کند.

مثال‌ها semantic باشند، نه تصادفی

اعداد و رشته‌های تصادفی contract churn می‌سازند و intent را پنهان می‌کنند. نمونه amountRial: 1250000, currency: IRR معنا دارد؛ عدد ۱۲۳ بی‌توضیح ندارد. error interactionهای مصرف‌شده مانند ۴۰۰، ۴۰۴، ۴۰۹ و ۴۲۹ را نیز ثبت کنید، نه فقط ۲۰۰.

Provider State مستقل باشد

هر interaction state موردنیاز خود را اعلام و مستقل setup/teardown کند. ترتیب Pactها نباید state بسازد. Provider verification باید حداقل لایه parsing و validation واقعی request را طی کند؛ Stub کردن پیش از آن می‌تواند garbage request را سبز کند. راهنمای رسمی Provider Verification همین مرز و اجرای محلی در CI را توضیح می‌دهد.

Broker بدون هویت نسخه، فقط انبار JSON است

برای تصمیم انتشار، باید بدانیم کدام نسخه Consumer قرارداد را منتشر و کدام نسخه Provider آن را verify کرده است. نسخه Pacticipant بهتر است commit SHA یا شناسه deterministic متناظر با artifact باشد. راهنمای Versioning در Pact Broker هشدار می‌دهد که versionهای ناسازگار میان publish و verification، Matrix و تصمیم deploy را خراب می‌کنند.

حداقل هویت:

• نام پایدار Consumer و Provider؛
• commit/artifact version دقیق؛
• branch؛
• environment و نسخه‌های واقعاً deployشده؛
• نتیجه verification و زمان؛
• supported release برای موبایل یا clientهای طولانی‌عمر.

Gate انتشار: can-i-deploy چه می‌گوید و چه نمی‌گوید؟

can-i-deploy در Pact Matrix را بررسی می‌کند تا ببیند نسخه در آستانه deploy با نسخه‌های ثبت‌شده در environment مقصد، verification سازگار دارد یا نه. این یک gate سازگاریِ شناخته‌شده است؛ نه گواه امنیت، performance، workflow کامل یا سلامت deployment.

چرخه صحیح:

1. Consumer test قرارداد را با version/branch منتشر می‌کند؛
2. Provider قراردادهای مرتبط را locally verify و نتیجه را منتشر می‌کند؛
3. پیش از deploy، can-i-deploy برای environment مقصد اجرا می‌شود؛
4. پس از deploy موفق، همان artifact version ثبت می‌شود؛
5. پیش از حذف support یک client قدیمی، پایان پشتیبانی آگاهانه ثبت می‌شود.

مستندات Recording deployments and releases تفاوت نسخه deployشده و release پشتیبانی‌شده را توضیح می‌دهد. اگر مرحله آخر حذف شود، Broker نمی‌داند واقعاً چه چیزی در production است و gate می‌تواند روی فرض غلط تصمیم بگیرد.

CDC برای Message؛ payload سبز، delivery هنوز ناشناخته

در interaction رویدادمحور، Consumer پیام را می‌خواند و Provider/Producer آن را تولید می‌کند. Terminology رسمی Pact تصریح می‌کند Message Pact فناوری صف را انتزاع می‌کند و روی payload تمرکز دارد؛ Mock واقعی topic/bus نیست.

پس Message Contract می‌تواند shape، metadata و توان handler/producer را بسنجد، اما این موارد به تست جدا نیاز دارند:

• partition key و ordering؛
• at-least-once delivery و duplicate؛
• retry، backoff و DLQ؛
• Outbox/Inbox و transaction boundary؛
• consumer group، permission و topic config؛
• schema registry compatibility در runtime؛
• replay و data retention.

برای gRPC نیز Contract باید Protobuf evolution، metadata، status و در صورت نیاز streaming semantics را در سطح مناسب ببیند؛ راهنمای تست gRPC این مرزها را پوشش می‌دهد.

E2E را بر اساس Composition Risk انتخاب کنید

E2E را فقط با معیار «پرتکرارترین journey» انتخاب نکنید. Composition Risk یعنی خطری که از ترکیب اجزای جداگانه ایجاد می‌شود:

• ترتیب reserve موجودی و authorize پرداخت؛
• rollback یا compensation پس از failure میانی؛
• انتقال identity/permission میان gateway و سرویس‌ها؛
• هم‌زمانی callback و timeout؛
• تفاوت config یا feature flag میان سرویس‌ها؛
• سازگاری migration و نسخه deployشده؛
• outcome کاربر پس از چند interaction سبز اما معنای ناسازگار.

برای هر journey، owner، entry state، run identity، داده مستقل، stop condition، Oracle و Evidence Pack مشخص کنید. edge caseهای هر API را در E2E تکرار نکنید.

مثال ایرانی: Checkout، Payment و Notification

فرض کنید Checkout سفارش ۱۲۵٬۰۰۰ تومانی را به Payment می‌فرستد؛ Payment با PSP بیرونی کار می‌کند و بعد از verify، رویداد PaymentConfirmed را برای Order و Notification منتشر می‌کند. callback ممکن است دیر، تکراری یا پس از timeout برسد. اپ موبایل نسخه قدیمی نیز هنوز فیلدی قدیمی را مصرف می‌کند.

ریسک	شاهد مناسب	چرا
Checkout مبلغ را با واحد اشتباه می‌فرستد	CDC Checkout→Payment + Unit invariant	client واقعی و field/currency صریح دیده می‌شود
Payment response فیلد لازم موبایل قدیمی را حذف می‌کند	CDC نسخه پشتیبانی‌شده + Matrix gate	مصرف‌کننده غایب از E2E نیز شناخته می‌شود
PSP قرارداد HTTP رسمی را تغییر می‌دهد	Adapter integration + sandbox	PSP قرارداد Pact شما را verify نمی‌کند
callback تکراری دو اثر مالی می‌سازد	Component + DB/Queue integration	transaction، idempotency و redelivery لازم‌اند
event payload با انتظار Notification ناسازگار است	Message CDC	payload و metadata edge را می‌سنجد
event دوبار تحویل می‌شود و دو پیامک می‌رود	Broker integration/failure injection	delivery semantics خارج از Message Pact است
Order پس از پرداخت و رزرو موجودی Paid می‌شود	E2E API journey	invariant چندسرویسی و composition را می‌سنجد
route production به نسخه قدیمی Payment می‌رود	Post-deploy smoke/trace	Broker contract deployment routing را نمی‌بیند
تاریخ گزارش در مرز تهران/UTC غلط است	Unit/Component + یک E2E منتخب	قاعده پایین و wiring زمان در path بررسی می‌شود

سه E2E کافی‌تر از صد E2E تکراری

برای این capability می‌توان سه path منحصربه‌فرد داشت: خرید موفق، timeout پس از commit با reconciliation، و موجودی ناموجود پس از تلاش پرداخت. حالت‌های ۴۰۰/۴۰۹/۴۲۹، رقم فارسی/عربی و جدول مبلغ در Contract/Component پوشش گسترده‌تری می‌گیرند.

داده هر اجرا باید tenant/run ID، authority مصنوعی، amount unit، timezone، schema/seed و TTL داشته باشد. راهنمای TDM و داده مصنوعی این بخش را تکمیل می‌کند.

وقتی CDC سبز و E2E قرمز است چه کنیم؟

نشانه	فرضیه محتمل	اولین شاهد
Consumer test قرمز	client/expectation/serialization Consumer	interaction diff و request واقعی
Provider verification قرمز	breaking change، Provider State یا matcher	جفت نسخه، state و response diff
can-i-deploy خیر/نامعلوم	ناسازگاری یا verification/deployment گمشده	Matrix و نسخه‌های environment
CDC سبز، E2E قرمز	config، routing، auth، data، chain semantics یا dependency runtime	run manifest و distributed trace
E2E سبز، CDC قرمز	journey مصرف‌کننده/حالت شکسته را طی نکرده یا environment قدیمی است	نسخه‌ها و coverage interaction
Message CDC سبز، duplicate failure	delivery/idempotency خارج قرارداد	message ID، attempt، Inbox/Outbox و ledger

مفهوم Trace در OpenTelemetry برای دنبال‌کردن یک request در چند سرویس مفید است. Trace خود Oracle نیست؛ باید به outcome دامنه، نسخه‌ها و run ID متصل شود.

مهاجرت از E2E سنگین به CDC + E2E هدفمند

1. هر E2E را به interaction assertion، composition assertion، UI assertion و deployment assertion تجزیه کنید؛
2. برای interactionهای بین سرویس‌های تحت‌کنترل، Consumer و Provider واقعی را مشخص کنید؛
3. CDC را با client production، examples معنادار و Provider State مستقل بسازید؛
4. عمداً breaking change ایجاد کنید و نشان دهید Contract قبل از E2E آن را می‌گیرد؛
5. version/branch، selectors، verification result و Matrix را در Broker درست کنید؛
6. can-i-deploy را ابتدا dry-run و سپس gate کنید؛
7. E2E را فقط به assertionهای composition/UI/deployment کاهش دهید؛
8. تست قدیمی را پس از اثبات safety net جایگزین حذف کنید؛
9. failureهای E2E باقی‌مانده را با trace و ownership قابل‌اقدام کنید.

هدف «حذف E2E» نیست؛ حذف تکراری است که Contract ارزان‌تر و دقیق‌تر می‌گیرد.

Pipeline پیشنهادی Consumer، Provider و Deployment

Consumer PR

Unit/Component و Pact Consumer test اجرا می‌شوند؛ Pact با commit SHA و branch منتشر می‌شود؛ تغییر contract قابل‌مشاهده است. انتشار Pact نباید با داده تصادفی artifact جدید بی‌دلیل بسازد.

Provider PR یا Webhook

Provider پکت‌های relevant برای branch اصلی، نسخه‌های deployشده/پشتیبانی‌شده و در صورت نیاز Pending/WIP را verify می‌کند؛ نتیجه فقط از CI مورداعتماد و با provider version دقیق منتشر می‌شود.

Pre-deploy

can-i-deploy –to-environment برای artifact در آستانه انتشار اجرا می‌شود. Missing verification نباید بی‌صدا success تلقی شود. بعد از gate سازگاری، laneهای migration، E2E منتخب، امنیت یا performance بر اساس ریسک اجرا می‌شوند.

Post-deploy

deployment همان نسخه ثبت می‌شود؛ smoke/canary و SLIها runtime را می‌سنجند. اگر deploy ثبت نشود، تصمیم نسخه بعدی ناقص می‌شود.

تفکیک laneها در راهنمای Continuous Testing و امنیت Runner/Artifact در راهنمای GitLab CI تشریح شده است.

معیارهای سالم برای CDC و E2E

• Known-edge coverage: چند یال فعال گراف، قرارداد و مالک معتبر دارند؟
• Active-version verification: چند نسخه deployشده/پشتیبانی‌شده Matrix کامل دارند؟
• Compatibility decision time: از commit تا جواب gate چقدر طول می‌کشد؟
• Stale contract age: interaction بدون publish/verification تازه چه مدت مانده است؟
• Orphan consumer/provider: edge ثبت‌شده‌ای که تیم یا pipeline فعال ندارد؛
• Breaking changes blocked pre-deploy: تعداد همراه با severity، نه هدف حجمی؛
• Contract-green/E2E-red gap: چه failure mechanismهایی بیرون قرارداد مانده‌اند؟
• E2E actionable failure rate: سهم قرمزهای دارای علت، owner و اقدام؛
• E2E p95 feedback/cost: زمان و runner cost هر Critical Journey؛
• Change amplification: تغییر interaction چند Contract و E2E را ویرایش می‌کند؟
• Unsupported-version exposure: client قدیمی بدون verification یا پایان پشتیبانی روشن؛
• Runtime escape learning: incident به Contract، Component، E2E یا Probe مناسب برگشته است؟

تعداد Pact file یا درصد E2E حذف‌شده KPI کیفیت نیست. contract زیاد با matcher ضعیف و deployment ثبت‌نشده می‌تواند false confidence را بیشتر کند.

مالکیت و سیاست مشترک میان تیم‌ها

• Consumer مالک expectation و حذف requirement منسوخ است؛
• Provider مالک state، verification و سازگاری نسخه‌های پشتیبانی‌شده است؛
• Platform مالک availability، backup، access و lifecycle Broker است؛
• هر edge یک owner و escalation path دارد؛
• هر Critical Journey یک owner برای داده، محیط و triage دارد؛
• شکستن عمدی contract با Expand→Adopt→Contract و مهلت مشخص انجام می‌شود؛
• exception در gate، owner، علت، expiry و rollback trigger دارد.

Contract artifact ورودی کنترل‌نشده از repository دیگر است؛ CI نباید secrets را در build نامطمئن یا fork آشکار کند. Broker نیز RBAC، TLS، backup، retention و audit لازم دارد.

برنامه ۳۰روزه

هفته اول: گراف و ادعاها

یک capability درآمدی انتخاب کنید؛ node/edge/path و نسخه‌های active را رسم کنید؛ ۲۰ E2E موجود را بر اساس Interaction/Composition/UI/Deployment دسته‌بندی کنید.

هفته دوم: یک edge واقعی

Consumer test را با client production و Provider verification را با state مستقل بسازید. یک breaking change کنترل‌شده ایجاد کنید و failure قابل‌تشخیص را ثبت کنید.

هفته سوم: Matrix و Gate

SHA/branch/environment، verification selectors و deployment record را درست کنید. can-i-deploy را در dry-run با سناریوهای compatible، incompatible و unknown آزمایش کنید.

هفته چهارم: E2E را باریک کنید

interactionهای منتقل‌شده را از دو E2E پرتکرار حذف کنید؛ composition assertion و trace را نگه دارید؛ p95، actionability، Matrix completeness و fidelity gap را قبل/بعد مقایسه کنید.

ضدالگوهای رایج

• گفتن «Contract سبز است، پس deploy امن است» بدون قید ادعای سازگاری؛
• ساخت Pact با HTTP نمونه به‌جای client واقعی Consumer؛
• matcher بسیار آزاد که type، enum، unit یا field لازم را نمی‌سنجد؛
• قفل‌کردن response کامل Provider به فیلدهایی که Consumer مصرف نمی‌کند؛
• Provider State مشترک و وابسته به ترتیب interactionها؛
• version تصادفی یا متفاوت میان publish و verification؛
• اجرای can-i-deploy بدون ثبت deployment واقعی؛
• نادیده‌گرفتن موبایل یا client پشتیبانی‌شده قدیمی؛
• استفاده از CDC برای API عمومی یا third-party بدون مشارکت Provider؛
• فرض اینکه Message Pact، broker و duplicate/ordering را تست کرده است؛
• تکرار همه interactionها در E2E؛
• ساخت journey عظیم با ده‌ها سرویس و بدون owner؛
• retry کردن E2E مبهم به‌جای trace، داده مستقل و classification؛
• جایگزینی Security/Performance/Resilience با CDC یا E2E functional؛
• حذف E2E پیش از اثبات safety net Contract/Component.

چک‌لیست تصمیم CDC در مقابل E2E

• ادعای هر تست و failure mechanism آن نوشته شده است.
• edge، path و runtime با هم اشتباه نشده‌اند.
• Consumer/Provider تحت‌کنترل و قابل‌شناسایی‌اند.
• قرارداد از client واقعی و مثال‌های semantic ساخته می‌شود.
• matcherها request را دقیق و response مصرف‌شده را منعطف اما ایمن می‌سنجند.
• Provider State مستقل و verification در CI محلی/قابل‌کنترل است.
• commit/branch/environment و active versions در Broker صحیح‌اند.
• can-i-deploy پیش از و record-deployment پس از deploy اجرا می‌شود.
• Message delivery semantics تست مستقل دارد.
• E2E فقط composition، UI یا deployment value منحصربه‌فرد دارد.
• run identity، data، trace، Oracle و owner هر E2E مشخص است.
• third-party، security، performance و production probe پوشش جدا دارند.
• مهاجرت، شواهد قدیمی را قبل از اثبات جایگزین حذف نمی‌کند.

پرسش‌های متداول CDC و E2E

آیا CDC می‌تواند کاملاً جایگزین E2E شود؟

خیر. CDC سازگاری interactionهای شناخته‌شده را می‌سنجد؛ composition چند سرویس، routing، config، auth و runtime واقعی بیرون ادعای آن‌اند. تعداد محدودی E2E/Smoke برای این ریسک‌ها باقی می‌ماند.

آیا can-i-deploy یعنی انتشار کاملاً امن است؟

نه. این ابزار بر اساس Matrix و نسخه‌های ثبت‌شده درباره سازگاری Contract تصمیم می‌دهد. امنیت، performance، migration، configuration و workflow باید شواهد و gateهای خود را داشته باشند.

برای PSP یا API شخص ثالث از Pact استفاده کنیم؟

اگر Provider قرارداد شما را verify نمی‌کند و state آن کنترل‌پذیر نیست، ارزش CDC محدود است. adapter test، schema/conformance، Stub، sandbox و probe کم‌خطر معمولاً ترکیب مناسب‌تری است.

چند تست E2E برای میکروسرویس لازم است؟

عدد جهانی وجود ندارد. برای هر Critical Journey یا Composition Riskی که پایین‌تر اثبات نمی‌شود، حداقل path لازم را نگه دارید. edge caseهای interaction را در Contract/Component پوشش دهید.

چرا Contract سبز است ولی E2E شکست می‌خورد؟

احتمالاً failure در چیزی بیرون contract است: نسخه deployشده، route، TLS، auth، config، data، delivery semantics یا invariant چندسرویسی. ابتدا run manifest و trace را با Matrix نسخه‌ها مقایسه کنید.

جمع‌بندی

CDC و E2E رقیب نیستند؛ دو عدسی با میدان دید متفاوت‌اند. CDC یال‌ها و سازگاری نسخه‌های شناخته‌شده را سریع و قابل‌تشخیص می‌سنجد. E2E چند مسیر باارزش را در ترکیب و استقرار واقعی می‌بیند. استفاده درست از اولی باید تعداد و دامنه E2E را کم کند، نه اینکه واقعیت runtime را حذف کند.

از یک گراف ساده شروع کنید: کدام edge قرارداد ندارد، کدام path composition risk دارد و Broker درباره نسخه‌های واقعاً deployشده چه می‌داند؟ سپس Contract را به Matrix gate، E2E را به Critical Journey و هر دو را به شواهد قابل‌اقدام وصل کنید.

منبع تکمیلی درباره مرز اطمینان

Google SRE: Testing for Reliability یادآوری می‌کند که پاس‌شدن تست‌ها reliability را اثبات نمی‌کند و ترکیب تست توسعه با مشاهده و آزمایش production برای مدیریت عدم‌قطعیت لازم است.