تست واحد سبز بودن هیچ ربطی به درستکارکردن سیستم زیر partition ندارد. سیستم توزیعشده نیازمند لایههای تستی متفاوت است: قرارداد بین سرویسها، تزریق خرابی، و بازبینیِ فرضهایی که «محال» به نظر میرسند.
هرم تست، نسخه توزیعشده
- Unit و Integration: قوانین دامنه و تراکنشها؛ سریع و فراوان.
- Contract Testing (مثل Pact): مصرفکننده انتظاراتش از API را بهصورت قرارداد ثبت میکند و provider در CI خودش را با آن میسنجد — بدون بالا آوردن همه سرویسها در یک staging هیولایی.
- End-to-End محدود و هدفمند: فقط مسیرهای طلایی؛ هر تست e2e شکننده مالیات دائمی است.
- Shadow / Mirroring: کپی ترافیک واقعی به نسخه جدید بدون سرو جواب به کاربر — مقایسه رفتار قبل از سوییچ (مکمل canary فصل ۶).
تزریق خرابی: از Chaos تا Jepsen
- Chaos Engineering (فصل ۶) را یک سطح عمیقتر کن: تزریق partition شبکه، کِشندن نود وسط تراکنش، duplicate/reorder پیامها، کندکردن دیسک — هرکدام یک فرض پنهان را میشکند.
- Jepsen سبکِ تحلیل: تستهایی که history عملیات را ضبط و بعداً بررسی میکنند آیا با مدل سازگاری ادعاشده (مثلاً linearizable) میخواند یا نه — همین روش باگهای معروف دیتابیسهای بزرگ را پیدا کرده است.
- Property-based Testing برای نامتهای دامنه: بهجای مثالهای دستی، هزاران سناریوی تصادفی بساز و بررسی کن «جمع دفتر کل همیشه صفر است» یا «هیچ سفارشی بدون پرداخت shipped نمیشود».
شبیهسازی قطعی
رادیکالترین روش (FoundationDB معروفش کرد): کل سیستم — شبکه، دیسک، ساعت — در یک شبیهساز قطعی اجرا میشود؛ هر تست با یک seed است، پس هر شکست دقیقاً قابل بازپخش است. ترکیب شبیهسازی + تزریق تصادفی خرابی = باگهای نابودگر را قبل از production میگیری. حتی اگر به این حد نرسی، درسش مهم است: قطعیسازی (determinism) بهترین دوست دیباگ توزیعشده است — لاگها را با trace_id و ساعت منطقی قابل بازپخش نگه دار.
به زبان ساده
تست سیستم توزیعشده یعنی عمداً شبکه را قطع، ساعت را به هم ريختن و پیام را تکراری کردن — ابزارهایی مثل Jepsen این جنون را علمی میکنند.
مثال واقعی
مثل تمرین اطفای حریق: آتش واقعی وقت تست نیست؛ در محیط امن، partition میسازی و میبینی آیا داده گم میشود یا نه — قبل از اینکه مشتری ببیند.