سبد خرید یک فروشگاه آنلاین یک‌دفعه تخفیف را غلط حساب می‌کند، بار دیگر هنگام پرداخت گیر می‌کند و بار سوم فقط برای کاربران یک مرورگر خاص از کار می‌افتد. هر سه مشکل «باگ»اند، اما در سه لایه متفاوت سیستم زندگی می‌کنند: منطق محاسبه، اتصال قطعه‌ها به هم، و تجربه کامل کاربر. برای همین هر کدام با نوع متفاوتی از تست گرفته می‌شوند.
این سه نوع — تست واحد (Unit Test)، تست یکپارچه (Integration Test) و تست سرتاسری (End-to-End Test) — جایگزین هم نیستند؛ حلقه‌های یک زنجیره‌اند که هرکدام بخشی از سیستم را می‌بینند. تیمی که فقط یکی را می‌شناسد، معمولاً همان یکی را برای همه چیز به کار میبرد و از نتیجه شگفت‌زده می‌شود.
در این مقاله هر سه مفهوم را با مثال از همان فروشگاه توضیح می‌دهیم، در جدولی کنار هم می‌گذاریم و مشخص می‌کنیم هر نوع تست دقیقاً کدام بخش از سیستم را پوشش می‌دهد و در کار روزمره از کجا باید شروع کرد.
مفهوم پایه؛ تست چیست و چرا لایه‌بندی می‌شود؟
تست خودکار یعنی نوشتن قطعه‌ای کد که رفتار بخش دیگری از کد را با ورودی مشخص و خروجی مورد انتظار می‌سنجد. ارزش اصلی آن تکرارپذیری است: هر بار که کد تغییر می‌کند، همه این بازرسی‌ها دوباره اجرا می‌شوند و تغییرِ شکسته به‌سرعت لو می‌رود.
اما یک دوگانه همیشگی وجود دارد: هرچه تست بخش بزرگ‌تری از سیستم واقعی را می‌بیند، واقعی‌تر است ولی کندتر، گران‌تر و شکننده‌تر؛ و برعکس. لایه‌بندی تست‌ها پاسخ همین دوگانه است: هر سطح، تعادلی متفاوت از واقع‌گرایی و سرعت ارائه می‌کند.
تست واحد؛ بازرسی منطق در مقیاس کوچک
تست واحد کوچک‌ترین بخش مستقل کد — یک تابع، یک متد یا یک کلاس — را در انزوا می‌آزماید. «واحد» یعنی همین قطعه کوچک، بدون پایگاه داده، بدون شبکه و بدون فایل. وابستگی‌های بیرونی با بدل تست (Test Double) جایگزین می‌شوند تا رفتارشان کاملاً کنترل‌شده باشد.
مثال: در فروشگاه آنلاین، تابعی تخفیف پلکانی را محاسبه می‌کند — مبلغ بالاتر، درصد بیشتر، با سقف مشخص. تست واحد همین تابع را با ورودی‌های مرزی می‌آزماید: سقف دقیق، یک ریال زیر سقف، صفر، مقدار منفی و ترکیب با کد تخفیف. اگر منطق محاسبه اشتباه باشد، این تست در کسری از ثانیه قرمز می‌شود و دقیقاً می‌گوید کدام ورودی خراب است.
تست یکپارچه؛ آزمون درزها و اتصال‌ها
بخش بزرگی از خطاهای نرم‌افزار نه درون یک تابع، بلکه در مرز دو قطعه رخ می‌دهد: سرویس و پایگاه داده، ماژول و صف پیام، کد و درگاه پرداخت. تست یکپارچه چند قطعه را واقعاً کنار هم می‌آورد و می‌بیند آیا حرف هم را می‌فهمند.
مثال: ثبت سفارش یعنی نوشتن در جدول سفارش‌ها، کسر از موجودی و فرستادن پیام به سرویس ارسال. تست یکپارچه همین جریان را با پایگاه داده آزمایشی اجرا می‌کند و کشف می‌کند که مثلاً نام یکی از ستون‌ها در نگاشت داده اشتباه است — خطایی که هیچ تست واحدی نمی‌بیند، چون بدل‌ها همه‌چیز را همیشه موفق جلوه می‌دهند.
تست سرتاسری؛ شبیه‌سازی کاربر واقعی
تست سرتاسری کل سیستم را از نشیمن کاربر می‌آزماید: مرورگر باز می‌شود، دکمه‌ها فشرده می‌شوند و مسیر کامل — از جست‌وجوی محصول تا رسید پرداخت — باید همان‌طور که کاربر تجربه می‌کند طی شود. این تست چیزی را می‌سنجد که کاربر می‌بیند، نه چیزی که کدنویس فرض کرده است.
مثال: مسیر طلایی خرید — جست‌وجو، انتخاب محصول، افزودن به سبد، ورود، پرداخت و نمایش رسید — به‌صورت خودکار اجرا می‌شود. همین تست است که می‌فهمد دکمه پرداخت در یک مرورگر خاص کار نمی‌کند یا صفحه رسید پس از به‌روزرسانی طرح، سفید می‌ماند.
مقایسه سه سطح کنار هم
| ویژگی | Unit Test | Integration Test | End-to-End Test |
|---|---|---|---|
| دامنه پوشش | یک تابع یا کلاس در انزوا | تعامل چند قطعه با هم | کل سیستم از نگاه کاربر |
| سرعت اجرا | بسیار سریع | متوسط | کند |
| هزینه نگهداری | کم | متوسط | زیاد |
| شکنندگی در برابر تغییر | پایین | متوسط | بالا |
| دقت در تشخیص علت خرابی | دقیق و آدرس‌دار | متوسط | کم؛ فقط می‌گوید جایی خراب است |
| تعداد منطقی در پروژه | بیشترین | متوسط | کمترین و هدفمند |
| وابستگی به محیط | تقریباً هیچ | پایگاه داده و سرویس آزمایشی | محیط کامل و داده واقعی |
هر نوع تست چه بخشی از سیستم را پوشش می‌دهد؟
تست واحد پوشش منطق است: قواعد کسب‌وکار، محاسبات و تبدیل داده‌ها. تست یکپارچه پوشش مرزهاست: اتصال به پایگاه داده، صف‌ها، سرویس‌های بیرونی و پیکربندی. تست سرتاسری پوشش تجربه است: یکپارچگی همه‌چیز در همان قالبی که کاربر می‌بیند.
از این نقشه، یک قاعده عملی درمی‌آید: هر باگ را در نزدیک‌ترین لایه به ریشه‌اش بگیرید. خطای محاسبه در تست واحد ارزان و دقیق گرفته می‌شود؛ اما اگر تنها راه کشفش تست سرتاسری باشد، هزینه‌اش چند برابر و پیام خطایش مبهم خواهد بود.
مثال کاربردی؛ یک قانون تازه، سه نوع خرابی
فرض کنید در فروشگاه قانون تازه‌ای اضافه شده: تخفیف فقط برای سفارش‌های بالای سقف مشخص و در ساعات خاصی از روز. سه سناریوی خرابی را کنار هم ببینید تا جای هر لایه روشن شود:
- خطای فرمول: مقایسه سقف به‌جای «کمتر از» با «کمتر یا مساوی» نوشته شده؛ تست واحد با همان مقدار مرزی قرمز می‌شود و ریشه خطا در چند ثانیه پیدا است.
- خطای اتصال: سرویس سفارش پس از تغییر شمای پایگاه داده، ستون ساعات تخفیف را نمی‌بیند؛ تست یکپارچه در محیط آزمایشی شکست می‌خورد و مرز خراب را نشان می‌دهد.
- خطای تجربه: پس از طراحی جدید صفحه پرداخت، بخش انتخاب ساعت تحویل روی موبایل زیر صفحه گم شده؛ فقط تست سرتاسری چنین چیزی را می‌بیند.
مزایا و محدودیت‌ها
تست واحد سریع و ارزان است اما اتصال‌ها را نمی‌بیند و اگر بدل‌ها با واقعیت فاصله داشته باشند، اطمینان کاذب می‌سازد. تست سرتاسری واقعی‌ترین سطح است اما کند و شکننده؛ شکست‌های ناپایدار (Flaky) آن اگر مدیریت نشوند، اعتماد تیم به کل سبد تست را می‌سوزانند. تست یکپارچه وسط ایستاده و در عمل به‌ازای هزینه، بیشترین ارزش کشف را دارد.
خطاهای رایج
- ساختن هزاران تست سرتاسری به‌جای لایه‌های پایین‌تر؛ نتیجه، خط لوله‌ای کند است که هیچ‌کس منتظرش نمی‌ماند.
- تست‌هایی که رفتار را نمی‌سنجند و فقط برای بالا بردن «پوشش روی کاغذ» اجرا می‌شوند.
- بدل‌های بیش‌ازحد که رفتار واقعی وابستگی‌ها را تحریف می‌کنند.
- داده آزمایشی مشترک و آلوده که نتیجه تست‌ها را غیرقابل پیش‌بینی می‌کند.
کاربرد عملی؛ از کجا شروع کنیم؟
- منطق حساس کسب‌وکار — محاسبه قیمت، اعتبارسنجی، مجوزها — را با تست واحد پوشش دهید.
- مرزهای بیرونی مانند پایگاه داده، صف پیام و سرویس‌های ثالث را با تعدادی تست یکپارچه واقعی ببندید.
- مسیرهای طلایی کاربر را با چند تست سرتاسری کم‌شمار و پایدار محافظت کنید.
- همه را به خط یکپارچه‌سازی پیوسته وصل کنید تا با هر تغییر اجرا شوند، نه فقط شبانه.
- هر باگ تازه را در نزدیک‌ترین لایه به ریشه‌اش به تست تبدیل کنید تا هرگز تکرار نشود.
نکات کلیدی این مقاله
- سه سطح تست جایگزین هم نیستند؛ هرکدام بخش متفاوتی از سیستم را می‌بینند: منطق، مرزها و تجربه کاربر.
- هرچه تست واقعی‌تر است، کندتر و شکننده‌تر است؛ لایه‌بندی، پاسخ این دوگانه است.
- باگ را در نزدیک‌ترین لایه به ریشه‌اش بگیرید تا تشخیص دقیق و هزینه کم باشد.
- تست یکپارچه اغلب کم‌توجهی‌شده‌ترین و پرسودترین لایه است.
- شکست‌های ناپایدار را جدی بگیرید؛ اعتماد تیم به تست‌ها به‌سختی ساخته و به‌راحتی از بین می‌رود.
سوالات متداول
Mock دقیقاً چیست و چرا در تست واحد از آن استفاده می‌شود؟
Mock یک بدل قابل کنترل از وابستگی است؛ به‌جای پایگاه داده یا سرویس واقعی، نسخه‌ای ساده که پاسخ از پیش تعیین‌شده می‌دهد. با این کار تست واحد سریع و مستقل می‌ماند و فقط منطق خودِ واحد آزموده می‌شود، نه رفتار وابستگی‌ها.
آیا تست سرتاسری خودکار جایگزین تست دستی می‌شود؟
برای مسیرهای تکراری و رگرسیون، بله؛ اما تست دستی اکتشافی — همان‌که انسان کنجکاو دنبال شرایط غیرمنتظره می‌گردد — همچنان ارزش دارد. ترکیب هر دو، واقع‌بینانه‌ترین تصویر کیفیت را می‌دهد.
اگر تست‌ها گاهی بی‌دلیل شکست بخورند چه کنیم؟
شکست‌های ناپایدار را جدی بگیرید: علت را پیدا کنید — انتظار زمانی، داده مشترک یا وابستگی به محیط — و برطرف کنید. تستی که قابل اعتماد نیست بهتر است موقتاً جدا و برچسب‌گذاری شود تا اعتماد تیم به کل سبد از بین نرود.
